• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 475 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.

ECan; safe to read mailbox contents before clearing RMP?

Jonathan Lock
Intellectual 775 points


Hey all,

Could someone clarify the recommended behavior when it comes to the ECan module and the order of reading the mailbox contents and clearing the associated RMP bit? In SPRUH18D, pg. 1097, "16.11.4, receiving a message" the recommended method of reading a message is to first clear the RMP bit, read the message contents, and then verify the RMP bit hasn't been set again (which would signify a partially corrupted read, with some bytes from the initial frame and some from a frame that had just been received).

Though the described method may be useful if it's critical not to miss new messages, in my application I'm buffering messages with the OPC functionality over several mailboxes and I *really* don't want to risk corrupting occasional messages by clearing the RMP bit first, which leads to my question;

Is it safe to read the mailbox contents before clearing the associated RMP bit?

Thanks!

  • 0
    TI__Guru* 95315 points

    Jonathan,

    If you are using multiple-mailboxes to buffer the received data, I don't see an issue with this approach. Having said that, have you determined if the # of mailboxes you have allocated for reception is adequate? IOW, is the application reading the mailboxes at a rate to prevent lost messages?

  • 0 in reply to Hareesh Janakiraman
    Intellectual 775 points

    Ok, thank you for the clarification. (FWIW it's too bad the manual explicitly states the RMP bit has to be cleared if it is in fact optional). I have far more mailboxes than I need (something like 15 receive mailboxes, I'm expecting a latency of *at most* two messages) so I am not at all worried about input buffer overruns.

    Thanks again!