CAN bus goes through periods of re-sending messages continually

Question

I'm having an issue where my microprocessor CAN bus module continuously re-sends its last message, even though it seems to be received properly by my USB-CAN monitor on the other end.

I'm attempting to implement the J1939 CAN bus protocol in a Microchip DSPIC30F4013 (with an ISO1050). I found a J1939 library from Microchip for a different chip family (PIC18xx) and have ported it over for my DSPIC30. The only nodes on the bus are my device-under-test and the USB-CAN monitor I'm using for debugging. I've mostly been using a Ginkgo USB-CAN Interface Adapter from ViewTool; I've also used the CANalyst-II some as well. Both the monitor and my DUT do have 120 ohm termination resistors.

My firmware has three command messages it can receive and two status messages it sends. I've never had an issue with sending the command messages from the CAN monitor to the DUT. My DUT has always done the thing it's supposed to do upon receiving that command, and I've never noticed anything crazy on the bus at those times.

Sending a status message, however, has consistently NOT behaved properly. The status messages alternate every two seconds: send msgA, wait 2s, send msgB, wait 2s, send msgA, ... ... At some point, a "condition" is being met that causes the CAN module to continuously re-send the last message. The difficult part is that it doesn't happen predictably or reliably. Sometimes it's immediately on power-up... sometimes it is seconds later... sometimes it doesn't happen for minutes.

Once I realized I had this problem, I added on some state-level logic to my 2-second trigger. Now I check the CAN status/results register(s) to see if the previous message ended properly. If not, I manually abort and then send the next message. This is kind of interesting in that now what the operation looks like is: send msgA, wait 2 seconds, continuously send msgB for the duration of the 2 seconds, send msgA, wait 2 seconds, continuously send msgB for the duration of the 2 seconds ..., ...

The part that most confuses me is how it seems to only affect one message at a time. If it were a module configuration problem, I would have expected all messages either sent and/or received to flake out.

Answer 1

All of the symptoms are consistent with the USB-CAN monitor operating in listen-only mode (not participating actively on the CAN bus). Or not understanding 29-bit messages, but that is unlikely (J1939 is explicitly listed).

From page 10 in the manual (bizarrely packed into a ZIP file), Ginkgo USB-CAN Interface VTG203B User Manual v1.1:

In tab Init Device, Working Mode should be "Normal". If it is "Silent mode" (or just "Silent"?) or perhaps some of the loopback modes, it would explain what you are observing.