• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 698 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.

Advisory CAN - Method to Service Multiple Interrupts

wolfgang kopp
Intellectual 440 points

In the SPRZ002E there we found this advisory: "The CAN_IFR bit that causes an interrupt must be cleared as early as possible within the ISR."

So we cleared the MIF bit the corresponding mailbox bits BEFORE we read out the data of the mailbox.

We had some lost messages then and think the mailbox can be overwritten by an new message if the MIF bit is cleared to early.

Now we clear bit MIF bit AFTER reading the mailbox again and stay as long in the interrupt as all MIF bit are reset. Is this correct?

Best regards,

Wolfgang

  • 0
    TI__Guru* 93985 points

    If the RMP bit of a mailbox is cleared before the contents are read, it is possible that the contents are overwritten by a subsequent message, especially when the interrupt latency is long. So your observation that MBX contents appear to have been over-written is possibly correct.

    I didn't understand what you mean by " stay as long in the interrupt as all MIF bit are reset..." Are you saying you stay as long as needed in the ISR, until all the MIFn bits in CAN_IFR register are cleared? After reading a MBX and clearing its RMP flag, do you read CAN_IFR again to see if any other MBX needs to be serviced? And exit the ISR only after determining there are no pending interrupts?

  • 0 in reply to Hareesh Janakiraman
    Intellectual 440 points

    Dear Hareesh,

    thanks for your answer.

    "After reading a MBX and clearing its RMP flag, do you read CAN_IFR again to see if any other MBX needs to be serviced? And exit the ISR only after determining there are no pending interrupts?"

    yes, you got that right. We have loop that checks the active mailboxes for 6 times. If the corresponding CAN_IFR bits are cleared we exit the ISR.

    Can you confirm this method?

    So should we ignore the advisory?

    Best regards,

    Wolfgang

  • 0 in reply to wolfgang kopp
    TI__Guru* 93985 points

    Wolfgang,

    It is hard to answer this without a thorough knowledge of your system. For example, how do you guard against lost messages , independent of this advisory? In other words, if your interrupt latency is long, there is a good chance that you could still lose messages, since you do not read the messages "soon enough". From your post, I gather that you have designed your system to ensure messages are not lost, as long as RMP bit is cleared only after reading the mailbox and that you ensure CAN_IFR bits are all clear before you exit the ISR. If this is working fine, then I do not see an issue with this approach.

  • 0 in reply to Hareesh Janakiraman
    TI__Guru* 93985 points
    Wolfgang,
    Just as a FYI, the eCAN module that you find in our 28xx devices aid in preventing lost messages. For starters, there are 32 mailboxes (instead o6 in LF240xA devices). It is also possible to protect a mailbox from being overwritten, so the CAN module will check other receive mailboxes for a matching ID. For example, you can configure 16 mailboxes for receive operation and protect them from being over-written.
  • 0 in reply to Hareesh Janakiraman
    Intellectual 440 points

    Dear Hareesh,

    at the moment we use 15 mailboxes for receive and 1 mailbox to transmit. In the interrupt routine we copy the messages from/into a ringbuffer as fast as possible. It only lasts a few microseconds.

    Best regards,

    Wolfgang

  • 0 in reply to wolfgang kopp
    TI__Guru* 93985 points

    Wolfgang,

    I am confused. Your original post refers to SPRZ002E, which pertains to LF240xA devices. Your last post refers to "15 mailboxes for receive and 1 mailbox to transmit", which is only possible with eCAN in the 28xx devices (or the D_CAN). Exactly which device are you using?