• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 397 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.

TMS320F28379D: Multi-frame CAN communication causing 'MsgLst' bit to be set in 'CAN_IF2MCTL' register.

Sumit Panse
Prodigy 100 points
Part Number: TMS320F28379D


Hi,

I am trying to handle CAN communication and see my mailbox assigned getting full causing 'MsgLst' bit to be set. I see this happening whenever the ISR is taking a bit longer than the rate at which the communication is happening.


I have tried out the following:
1. Tried to slow down the communication from the sender-end.

2. Implementing FIFO behavior for the mailboxes.

The first change (point '1' above) didn't help much, and I am facing problem handling the FIFO behavior. Can you please share an example reference in handling the FIFO behavior for mailboxes?

Regards,

Sumit

  • 0
    TI__Mastermind 38710 points

    Hi Sumit,

    Wanted to understand first what is in the interrupt routine that is causing messages to be lost before going into FIFO.  Arbitration and receiver ACK should be able to manage bus traffic to ensure that messages are handled properly.  Could there be some other routines added in the ISR that unnecessarily prolongs its execution?

    Thanks,

    Joseph

  • 0 in reply to Joseph Casuga
    TI__Guru* 95315 points

    Sumit,

       I presume the application is "busy" with other (non-CAN related) tasks that it is not able to service the CAN receive interrupts in time, leading to messages getting lost. You could configure multiple message objects with the same MSGID, but the EoB bit value will be different for the last message object. i.e. there is nothing special about configuring a FIFO. You configure the objects the same way, with the exception of the EoB value for the last object.

  • 0 in reply to Hareesh Janakiraman
    Prodigy 100 points

    Hi Hareesh,

    Yes, your assumption for application being "busy" is correct, just one point to note is that the application is a bare-metal application, no RTOS concepts here.

    As you suggested, I have the configuration for mailboxes set as a FIFO, but I'm facing problem while reading out from FIFO. I have looked into the interrupt based handling of FIFO read (Figure22-12 of TRM "SPRUHM8I" for TMS320F28379D), but if I could get help with the sequence on reading from FIFO with an example code, that would be great.

  • 0 in reply to Joseph Casuga
    Prodigy 100 points

    Hi Joseph,

    The application is busy in pushing the data fetched from the mailbox to a local FIFO buffer. That's the only thing the ISR needs to do & we don't have any other routines there that prolong the execution time.

    Please have a look to my reply to Hareesh's suggestion, that would explain in more depth the problem I'm facing with FIFO implementation of mailboxes.

  • 0 in reply to Sumit Panse
    TI__Guru* 95315 points
    Sumit Panse said:
    but I'm facing problem while reading out from FIFO.

    Exactly what problem are you facing?

  • 0 in reply to Hareesh Janakiraman
    Prodigy 100 points

    Hi Hareesh,

    Apologies for the delayed reply. I was able to solve the problem without using the FIFO implementation for mailboxes.

    The problem was that the ISR serviced all mailboxes at one-go during which an already serviced mailbox was getting new data ('NewDat' flag for that mailbox was observed to be set). Since the CAN_ES register was already cleared during the on-going ISR cycle for all the mailboxes, the next time ISR is executed, CAN_ES register returns ZERO (no error) thereby the mailbox was never serviced (or I should say emptied), thereby going overwritten by new data after that time & 'MsgLst' bit was set.

    Thanks for your support.

  • 0 in reply to Sumit Panse
    Prodigy 100 points

    Hi Joseph,

    The root-cause for the problem was with the way ISR was handling interrupt service. Please refer the answer to this discussion for more detailed explanation.

    Thanks for your support.

  • 0 in reply to Sumit Panse
    TI__Guru* 95315 points

    Sumit,

        I am glad the problem got resolved. Why are you relying on CAN_ES register when you are using interrupts?