Search code examples
can-busj1939

CAN J1939 device stops responding after communication timeout


I'm a higher layer guy, I don't and don't want to know much about , or even particular ECUs. I just don't like the software solution, so I'd like to ask, if customer's requirements are legitimate.

  1. If particular ECU doesn't receive CAN frame within 300 ms timeout after powerup, it stops responding to any further frames and must be power cycled. This is a information from customer's technicians, I have to just believe it.
  2. It is possible to powerup ECU after CAN driver thread is ready, but it would require some extra wiring by end customers.
  3. Software solutions are all bad or worse, like running FreeRTOS before important checks, put CAN driver code to code common with other products, or start CAN periphery in the bootloader and left running without software control until driver starts.
  4. The sensitive part is, that we have no explicit demand to start CAN driver within such a short time in specification. Customer says, that it's part of J1939 specification.

Can someone confirm or disprove, that J1939 allows devices to unrecoverably stop receiving after 300 ms of silence or requires devices to start transmitting within 300 ms after powerup? Or at least guide me to parts of J1939 standard, which could possibly regard this?

Thank you


Solution

  • My colleague answered, that there's no such demand, only vague 300 ms timeout.