Hangs when NMEA bus active?

[ro...@redpoint.org.uk]

Hi,

I have a version 3.5 board running the latest release, 1.3.1 ...

All looks fine, the little green light blinks as expected, the serial bus dribbles out AST messages. I hook it up to an NMEA2000 network (with a single B&G Triton2 display), and as soon as the network boots, the smart alt stops blinking, the serial output stops and the smartalt appears to hang ...

Network discovery on the Triton appears to find some device at address 128, but no serial number or model id, manufacturer etc, and no data PGN's appear to be detected by the Triton ...

Clues?  Did I miss a memo?

[ro...@redpoint.org.uk]

Well, a bit more digging ... I have two of these ... if I daisy chain them, they are fine, happy to co-exist on the bus together. If I then add my Triton2, one of them stops and hangs.

If I power up with power to all 3 units (the Triton2 and both SmartAlt) one of the smartalts will hang, its  random which one it will be.   If I power up with the Triton2 and one SmartAlt powered,  that one hangs every time, and when I then power up the second SmartAlt, it runs and delivers data.

When I turn off the Triton2 the hung SmartAlt device reboots and starts talking again.

My guess is it is something in the Triton2 network discovery/enumeration that is repeatedly  polling the first SmartAlt with some sort of interrogation message and keeping it busy or hanging it up, it doesn't recognise the 2nd device as "different" so doesnt bother sending that message.

I'm going to need some way of viewing/recording all the actual data on the NMEA2000 bus to find out what is going on ... any ideas?

[Al Thomason]

You know,

 

Might be something with the NMEA2000 device request / definitions.   IIRC this did work in the past when I checked (Been a VERY VERY long time it seems!).   But your description here of hands when you boot the Triton.  You might check to lib around Timo’s device name/if  (ref initialize_CAN(void) in OSEnergy_CAN.cpp)

 

There are details in the N2K spec where some information is not broadcasted, but made available in request.  It could be (??) you are on to something here, that the Tritan is making a request for things like Manufactures ID, model, etc.  And either Timo’s lib is downrev with an issue, or the VSR code is not passing on correct info to some of the calls in initial_CAN();

 

-al-

--
You received this message because you are subscribed to the Google Groups "Smart Alternator Regulator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-alt+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smart-alt/8f7f6ee5-8ae9-4323-aa19-0fb33bcd145bn%40googlegroups.com.

[Al Thomason]

Hello!

 

Not specifically, but some ideas ---

 

·        Maybe a CAN isolation issue?  Not sure, but the VSR does not have isolated CANs.  Mostly I am troubled when you said plugging in the CAN caused one to stop blinking and the ASCII to also stop.   You might check the CAN wiring – just connect up CAN-H and CAN-L, then leave the ground reference come in via the Vbat- post

·        What happens with just two CSR regs?  Do they seem to work with each other fine?

·        I am not sure there is anything in the CAN messages (ala, discovery, etc) that can cause a VSR to wedge.  Thinking it is more likely hardware.  Note also that there is power on the CiA_303 RJ45 pins, but might not be consistent with anything else on the N2K network – again, just try CAN H/L to the N2K network and see if that helps.

 

Al

 

 

From: 'ro...@redpoint.org.uk' via Smart Alternator Regulator [mailto:smar...@googlegroups.com]

Sent: Wednesday, February 15, 2023 3:52 PM
To: Smart Alternator Regulator

--

You received this message because you are subscribed to the Google Groups "Smart Alternator Regulator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-alt+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/smart-alt/dea66781-f4a8-44c6-b1d1-4ea6f00050c9n%40googlegroups.com.

[Robin Szemeti]

Yep, it is something in the sending of product information,  if I comment it out, it runs fine ... but otherwise, as soon as it gets a PGN 126996it craps itself and runs setup() again.

I shall dig further ...

      case 126996L: /* Product information */
        // If query was for us, try to respond immediately
        //if ( ( N2kMsg.Destination!=DeviceInformation[iDev].N2kSource ) || !SendProductInformation(iDev) ) {
        // DeviceInformation[iDev].SetPendingProductInformation();
        //}
        break;

On Fri, 17 Feb 2023 at 00:56, Robin Szemeti <ro...@redpoint.org.uk> wrote:

·        What happens with just two CSR regs?  Do they seem to work with each other fine?

yes fine with just two VSR

I am only using CAN_H and CAN_L, no ground ...  with the Triton on the buss vut unpowered its fines .. even when powered its fine until halfway through the Triton boot process and then one of the VSR's hangs .... if I power one VSR and the triton, it hangs ... if I then add the second VSR that runs OK and I can see amps/volts on the triton .. I don't thinks its hardware, I really do think it is a messaging thing.

On Fri, 17 Feb 2023 at 00:52, Robin Szemeti <ro...@redpoint.org.uk> wrote:

Hi Al,

It is definitely "talking" OK on the bus OK, I am monitoring levels on a scope and they are fine and when I get the two SmartAlt units on the bus with the B&G Triton, one will always hang, the other will be "alive" and the Triton2 can sort of see one unit (it doesn't get the name, software version, manufacturer etc) but it does see the PGNs for volts/amps!   It's random which will hang and which will run when the Triton is on the bus ... they are fine until the Triton boots and starts "talking" to the bus.

It's just a bit worrying to think a "funny" message on the NMEA bus could cause the unit to hang and stop the batteries charging, so I do want to sort it!

These are the two very last units you had and very kindly sold me on the basis of "they may need a bit of work to get going", one I just added the USB connector and flashed it and it was fine, the other needed a USB and the i2c bus hung up, turned out to be a bad processor but changed it and it's fine now, easy fix.

I'll keep playing with it, I may try updating Timo's library to the latest version.

I did find a couple of small things related to the #ifdefs for OSE and NVC functionality that stopped it compiling without those features enabled, but sorted that out. I'll fiddle with it over the weekend and let you know what I find.

[ro...@redpoint.org.uk]

The problem is in here ...

bool tNMEA2000::SendProductInformation(int DeviceIndex) {
  if ( DeviceIndex<0 || DeviceIndex>=DeviceCount) return false;
  tN2kMsg RespondMsg(DeviceInformation[DeviceIndex].N2kSource);

    if ( ProductInformation==LocalProductInformation ) {
/*
      SetN2kProductInformation(RespondMsg,ProductInformation->N2kVersion,
                                          ProductInformation->ProductCode,
                                          ProductInformation->N2kModelID,
                                          ProductInformation->N2kSwCode,
                                          ProductInformation->N2kModelVersion,
                                          ProductInformation->N2kModelSerialCode,
                                          ProductInformation->SertificationLevel,
                                          ProductInformation->LoadEquivalency);
*/
    } else {
 //!!     SetN2kPGN126996Progmem(RespondMsg,ProductInformation);
    }
    Serial.println("msg completed");
    delay(20);
    return true;
    //return SendMsg(RespondMsg,DeviceIndex);
}

####

SetN2kProductInformation() and SetN2kPGN126996Progmem() appear to screw with the stack somehow and when return is called, the thing crashes and runs setup() again and starts fresh.   It doesn't matter if you just return true; or return SendMsg(RespondMsg,DeviceIndex);  it still crashes as it returns.  If I comment out the call to SetN2kProductInformation() and just return true; at the end it runs fine (albeit the Triton2 keeps asking for product info again and again) but anyway .. thats where I got to last night.  

I'll keep digging!

[Robin Szemeti]

And found it :)

In N2kMsg.h  the max length of the databuffer is set as 76 bytes

static const int MaxDataLen=76; // For the alt reg we will only support small messages.  1 starter + 10 follow-on frames.

And the buffer is declared at this length.

Unfortunately in N2kMsg.cpp when stuff is added to the buffer eg Data[Index++]=Foo; ... while much effort is made to check the MaxLength of stuff that is about to be added ... no attempt is made to boundscheck the value of Index and and it will write clean off the end of the buffer into whatever else is out there.

Increasing MaxDataLen to 200 solved it.

You received this message because you are subscribed to a topic in the Google Groups "Smart Alternator Regulator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-alt/N8uFgHkzMeI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smart-alt+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smart-alt/ab62ccbd-c5ed-40a5-90b4-f8483138f8a3n%40googlegroups.com.

[al thomason]

You might check to call parameters.  There are details around ram vs flash.  Might be some things have changed or not just quite right

That the unit gets called again kind of sounds like the watchdog it being tripped?  Ala, for the code wedging and the wd timing out?

It has been a while sense I looking at this code, or combined it 😏

Al

To view this discussion on the web visit https://groups.google.com/d/msgid/smart-alt/ab62ccbd-c5ed-40a5-90b4-f8483138f8a3n%40googlegroups.com.