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

TMS320F28386D: CAN FIFO mode data reception while reading

Clément Letonnelier
Expert 2426 points
Part Number: TMS320F28386D

Hello,

I was going through the TRM and read the following:

All message objects of a FIFO buffer needs to be read and cleared before the next batch of messages
can be stored. Otherwise true FIFO functionality cannot be guaranteed, since the message objects of
a partly read buffer will be re-filled according to the normal (descending) priority.

In our application, we are checking every 1ms if we have received data on the CAN bus, meaning that in worst case between each check, we can receive from 4 to 7 frames depending on the payload size of the messages.

Emission won't stop while we retrieve these data so I can fairly imagine a corner case where I would be receiving a new frame while emptying the FIFO.

How do you recommend to handle it in order to guarantee the FIFO functionality ?

Regards,

Clément

  • 0
    TI__Mastermind 22810 points

    Hi Clement,

    Please expect a reply early next week, our CAN expert is out of office at the moment.

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    TI__Guru* 93755 points

    Clement,

                    There indeed could be a corner case as you have pointed out. Have you done a worst-case analysis of your CAN traffic? What is your bit-rate? What is the minimum/maximum frame length in the CAN traffic?

  • 0 in reply to Hareesh Janakiraman
    Expert 2426 points

    Hareesh,

    Hum the fact that there could be a corner case is not acceptable for me.

    I guess I'll need to define expected message ids instead of using the FIFO mode.

    I haven't done a worst-case analysis of our CAN traffic for now as this is a provision interface in our system.

    Our bitrate is 500kbps, frames aren't defined at this stage so we could expect frames with 1 to 8 bytes.

    But whatever the frame size, we don't intend to react on interrupts, we will rather unstack messages on a cyclical basis (every 1ms).

    Clément

  • +1 in reply to Clément Letonnelier
    TI__Guru* 93755 points

    Clement,

                    Considering transmission from the remote node(s) is asynchronous, there will always be a possibility that you could be receiving a new frame while emptying the FIFO. This is irrespective of the bit-rate or frame size. Would you agree? 

    I can think of one idea: CAN_TEST register contains a bit called RX, which monitors the actual value of the CANRX pin. Assuming a reception is ongoing, if you monitor this pin for 6 bit-times, it must go low at least once (due to the bit-stuffing rule). In your case you may need to loop for 12 uS. If the bit is sensed low, you could wait until the reception is complete, empty the FIFO and then go back to your main routine. Would that work for you? 

    On a different note, I wanted to bring your attention to this erratum: During DCAN FIFO Mode, Received Messages May be Placed Out of Order in the FIFO Buffer. Please see page 9 of www.ti.com/lit/sprz458.

  • 0 in reply to Hareesh Janakiraman
    Expert 2426 points

    Hareesh,

    Hareesh Janakiraman said:
    Considering transmission from the remote node(s) is asynchronous, there will always be a possibility that you could be receiving a new frame while emptying the FIFO. This is irrespective of the bit-rate or frame size. Would you agree? 

    I totally agree, that's what I was concerned about and wanted to have confirmation.

    Hareesh Janakiraman said:

    I can think of one idea: CAN_TEST register contains a bit called RX, which monitors the actual value of the CANRX pin. Assuming a reception is ongoing, if you monitor this pin for 6 bit-times, it must go low at least once (due to the bit-stuffing rule). In your case you may need to loop for 12 uS. If the bit is sensed low, you could wait until the reception is complete, empty the FIFO and then go back to your main routine. Would that work for you? 

    No that would not work, if we are at the start of the transmission it would stuck our SW during 250 to 300 µs (if not more) depending on the bit stuffing which is a third of our real time cycle.

    We didn't want to but I guess we will need to filter based on expected frame ids.

    Hareesh Janakiraman said:
    On a different note, I wanted to bring your attention to this erratum: During DCAN FIFO Mode, Received Messages May be Placed Out of Order in the FIFO Buffer. Please see page 9 of www.ti.com/lit/sprz458.

    Thanks for pointing out. Fortunately, it would not necessarily be an issue for us.

    Many thanks for taking the time to answer my question.

    Clément