• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 849 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28335: CAN Rx – when to clear RMP ?

Giles Robnson
Expert 1495 points
Part Number: TMS320F28335

Ref the eCAN Reference Guide - SPRUEU1

I am needing to handle a lot of CAN messages arriving in a short time. Following the guide, I plan to set up several mailboxes to receive the messages, protecting all but the one with the lowest number, and interrupt when messages arrive.

Section 3.2.4 Receiving a Message says

This example uses mailbox 3. When a message is received, the corresponding flag in the receive message pending register (CANRMP) is set to 1 and an interrupt can be initiated. The CPU can then read the message from the mailbox RAM. Before the CPU reads the message from the mailbox, it should first clear the RMP bit (RMP.3 = 1). The CPU should also check the receive message lost flag RML.3 = 1. Depending on the application, the CPU has to decide how to handle this situation.

After reading the data, the CPU needs to check that the RMP bit has not been set again by the module. If the RMP bit has been set to 1, the data may have been corrupted. The CPU needs to read the data again because a new message was received while the CPU was reading the old one.

It seems to me that if I clear RMP in a protected mailbox before reading the data, then I am inviting the peripheral to overwrite the data, even if there is another empty mailbox which could be used. Thus I think I should be (1) Reading the data and then (2) clearing RMP.

If the mailbox is protected, this should be OK as no new message can be stored in the mailbox until after the read.
But if it is not protected, and RML was already set before the read, I suppose that leaves no way to determine if the data has been overwritten/corrupted?

Am I missing something? Any help appreciated.

  • 0
    TI__Guru* 95315 points
    Since Receive happens asynchronously, there is always the possibility of a race condition. Probability of a message being overwritten is highly dependent on your bus load, CPU load (how quickly the CPU is able to read the received messages), number of mailboxes you are able to dedicate to the receive function etc. For your specific situation, you are doing the right thing by allocating multiple MBXes for receive, setting the OPC bits for all but the last MBX. This is the right thing to do.

    To your specific question about clearing the RMP bit, I agree with your assessment that it does leave open the possibility that the MBX could be overwritten. Think of a scenario when you clear the RMP bit, but a high-priority interrupt happens right then that you must service. In the interim period, a new message could always overwrite the old one. But bear in mind that even at 1 Mbps, it would take about 100 uS for the next frame to arrive (assuming an average frame length of 100 bits), which translates into several thousand CPU cycles. So, whether or not a message would get lost is highly dependent on the application.

    RML being set does indicate that the message was overwritten.
  • 0 in reply to Hareesh Janakiraman
    Expert 1495 points
    Thank you. Very nice answer.