This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PZ: CAN Bus Transmit interrupt

Part Number: TM4C123GH6PZ

I am trying to configure the CAN peripheral on the TM4C device I am using on a custom PCB, to 1 MBaud and using the TX interrupt on a message object. Each time the TX interrupt is called, I would like to pop a byte off a circular buffer and use the CANMessageSet() API call to send it. As I understand it, as long as I don't see any error interrupts, the byte should be sent properly by the hardware, with no additional work on the part of the application. However, when I look at the CAN bus using a CAN analyzer, I see that some bytes are missing. This is despite the CAN TX ISR firing the correct number of times (i.e. the CANMessageSet() function is called with the correct byte sequence and the correct # of times). Can anyone shed light on what I might need to look into here? Here is my ISR:


Here is my setup code:

Please disregard some of the extra code as I am configuring a number of different TX and RX mailboxes in order to implement a "mux-demux"-type UART-CAN bridge app.


Thanks!

- A.G.

  • Hello Abhimanyu

    Can you please share the results from the CANAnalyzer?
  • Hi,

    I am using a USB CAN analyzer and then viewing the output using candump (via Socket CAN). From the TM4C, I am trying to send a string, but when I display the corresponding ASCII representation of the DLC 1 CAN packets on the PC, I see there are bytes missing. However, I know for a fact that the CAN TX ISR is being called the correct number of times because I am printing debug output over a UART within the ISR each time I hit it.

    Thanks,
    - A.G.
  • Hello,

    In some further work involving this issue, I decided to try just doing a simple polling+blocking-driven CAN transmit loop as a basic proof-of-concept, to eliminate some of the complexity of interrupts. I came up with the following code: http://pastebin.com/amBQMNvm. I attempted to implement some suggested fixes from e2e.ti.com/.../406495 as you can see in the code (basically, I tried either blocking until the TXOK flag was set using the standard CANStatusGet(), and then wrote a modified loop that functionally does the same thing but only clears the necessary bits after the completion of the blocking section. Neither solution works, as shown by the output here: http://pastebin.com/yg4XRG52. As you can see, what should be a constantly-incrementing series of DLC 1 CAN packets is anything but that.

    I would greatly appreciate any insight into this matter, as I have been trying to solve this issue for a fairly long amount of time.

    Thanks!
  • Hello Abhimanyu

    The pastebin site is a blocked site from TI network. Can you run the basic can example provided in DK-TM4C123G application to see if the code base provided works as expected?