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

Part Number: TMS320F28386D
Other Parts Discussed in Thread: TEST

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

  • Hi Clement,

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

    Best Regards,

    Marlyn

  • 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?

  • 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

  • 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.

  • Hareesh,

    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.

    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.

    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