• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 244 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28379D: CAN Message object never sent

Paul Thomas
Prodigy 30 points
Part Number: TMS320F28379D

Hello, we're seeing a problem where a CAN message is never sent. This only happens about 1 time in 1000. I can trap the end of this condition using a timeout of the TX interrupt never being received. Even making the timeout very large, up to 1 second it does the same thing. In a normal case CAN_O_NDAT_21 is 0x80000 before the interrupt and 0 after. In the unsuccessful case it stays 0x80000 after the timeout.

This only happens in the presence of other CAN traffic. It's almost like the processor lost arbitration and never retried, but CAN_CTL.DAR is 0. This is using the F28379D.

Is there any hardware path for a message object to get retired (CAN_O_IF1MCTL.TxRqst is 0) without successfully transmitting the message? What else can I poke at in the failed case to see what is going on.

thanks,

Paul

  • 0
    TI__Guru* 95315 points
    Paul Thomas said:
    Is there any hardware path for a message object to get retired (CAN_O_IF1MCTL.TxRqst is 0) without successfully transmitting the message?

    No. If DAR is 0, the message will get transmitted eventually. TxRqst only gets cleared when the transmission is complete. Is it possible that the message went out but the interrupt was not asserted? How are you monitoring the messages on the bus? Are you using a CAN bus analyzer?

    Please check the debug tips in www.ti.com/lit/SPRACE5. 

  • 0 in reply to Hareesh Janakiraman
    Prodigy 30 points

    I'm watching this with wireshark using Linux socketcan with a PCAN adapter. Currently I have it set for a 500ms timeout, and you can see nothing comes through:

    So I don't think it's just an issue with the interrupt clearing (I spent a lot of time on this yesterday).

    (btw, edited above, the CAN_O_IF1MCTL reporting was wrong)

    Does it mean something that CAN_O_NDAT_21 still has that bit set after 0.5 seconds? Is there a way to see how many times it has retried?

    thanks,

    Paul

  • 0 in reply to Paul Thomas
    Prodigy 30 points

    Hmm, maybe this is just the PCAN adapter. I am seeing kernel messages like this:

    [125054.082248] peak_usb 3-2.4.4:1.0 can0: Rx urb aborted (-71)
    [125077.886850] peak_usb 3-2.4.4:1.0 can0: Rx urb aborted (-32)

    Even if I set the timeout all the way up to 2 seconds this doesn't work.

    -Paul

  • 0 in reply to Paul Thomas
    TI__Guru* 95315 points
    Paul Thomas said:
    Is there a way to see how many times it has retried?

    No.

    If a specific ARBID ("message ID") is missing, you could setup your scope to trigger on that ID. Once a message is marked for transmission, it will eventually get transmitted, provided of course, nodes with higher priority messages do not dominate the bus completely.