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.

TMS320F280037: Sending multiple messages from multiple CAN message objects seems to cause communication blocking.

Part Number: TMS320F280037

Hi Team,

Here's an issue from the customer may need your help:

There are multiple CAN message objects (about 10) set up in my application that are responsible for sending CAN messages (standard format). The sending process is in a task function that is executed every 10ms. During use, I found that the CAN bus would stop working quickly after starting to send several messages. It is judged that it occurs when "two or more message objects send information in these 10ms". As a temporary solution, a semaphore-like variable is introduced to constrain all CAN message objects to ensure that in a 10ms period, only one message object will send information at most. But this temporary solution is less than ideal. The CAN communication baud rate is set at 500k, which should not be caused by excessive communication volume. 

Now what I want to ask is based on experience, what are the possible factors that may cause this situation? Have any similar problems/solutions been raised before?

--

Thanks & Regards

  • Hi Yale,

    10ms frame sending duration at 500kbps should be more than enough space.  It would be hard to pinpoint what is causing the other message objects not to be sent with limited details on the application but i would start with asking customer these questions:

    1.) Is the CAN transmission routine done through ISRs?  If so, make sure that the application is acknowledging and clearing the interrupts.  An interrupt overflow happens when interrupts are not cleared and acknowledged and would cause further instructions not to be carried out.

    2.) What are the values seen in the CAN_ES (error status) register?  This register monitors if there is a bus off condition that would prevent any frames from being sent unless the bus has recovered.  The register also will indicate if there are parity errors, bit errors or states of the error counters and last error code from the latest CAN transaction.  This should be the first register to be inspected.

    Best regards,

    Joseph