3
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ Is it expecting an acknowledge at the end of the message? \$\endgroup\$
    – Andy aka
    Nov 2, 2015 at 22:26
  • \$\begingroup\$ @Andyaka I'm not entirely sure what you mean... Yes, a CAN bus message must be ACK'd by a receiver, but that is handled by the CAN module directly. That's not something I have do at my firmware level. \$\endgroup\$
    – Adam Head
    Nov 3, 2015 at 16:11
  • \$\begingroup\$ This sounds a whole lot like a software bug in the microcontroller. \$\endgroup\$
    – Lundin
    Nov 6, 2015 at 7:22

1 Answer 1

2
\$\begingroup\$

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.

Screenshot of the place to set the mode, e.g. listen-only

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.