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.

TMS320F28388D: DCAN what happens when EOB is not set for single message object?

Part Number: TMS320F28388D


Tool/software:

According to the Technical Reference Manual for the 2838x, the DCAN End of Block flag should be set to 1 when working with a single message object.

[EoB value of 1 indicates] The message object is a single message object or the last message object in a FIFO Buffer Block.

Note: This bit is used to concatenate multiple message objects to build a FIFO Buffer. For single message

objects (not belonging to a FIFO Buffer), this bit must always be set to one.

In our application each mailbox is configured to send or receive a single CAN ID. I was stress testing our MCAN and DCAN implementations to see what happens when messages are not read as fast as they are received and noticed an unexpected (and apparently undefined) behavior. Here is a snippet of the code to illustrate the mailbox configuration:

  frame = CAN_MSG_FRAME_STD;
  filter = CAN_MSG_OBJ_USE_ID_FILTER;

  filter |= CAN_MSG_OBJ_FIFO; // Toggle EoB here

  CAN_setupMessageObject(obj->portHandle, aMailBox + 1, aId, frame,
                         CAN_MSG_OBJ_TYPE_RX, 0x1FFFFFFF, filter,
                         aLen);

- With EoB = 0, we read the most resent message sent (older messages appear to be overwritten)

- With EoB = 1, we read the first message sent since the last read (new messages are thrown away)

Personally I refer the first option, where I receive the newest data. I don't want to operate on stale data. We provide a general purpose tool, so it would be preferable to me to always have fresh data as a default, in case a user has configured their CAN reads at an imperfect rate relative to the message transmit rate. However the documentation seems to suggest this is an erroneous configuration and the behavior (which seems consistent in my testing) would appear to be undefined. 

Can you comment on the use of EoB for single message objects? If I expected anything it would have been the reverse of these results.

Thanks!

Zia

  • Hi Zia,

    Can you clarify how you were able to confirm that messages are thrown away with EoB=1?  Are you just polling the message object or are you using an ISR to read out the message object when a new data is available?

    Thanks,

    Joseph

  • Hi Joseph,

    Looking a little deeper I see that the polarity of CAN_MSG_OBJ_FIFO was not what I expected (below from the driverlib can.c):

    // If this is a single transfer or the last mailbox of a FIFO, set EOB bit.
    // If this is not the last entry in a FIFO, leave the EOB bit as 0.
    //
    if((flags & CAN_MSG_OBJ_FIFO) == 0U)
    {
      msgCtrl |= CAN_IF1MCTL_EOB;
    }
    In this case the behavior of EOB is opposite if what I said above and does behave the way I would expect. 
    It's probably not relevant any longer, but to answer your question: I am polling and retransmitting a CAN message at 10ms on the 2838x and using KVaser CanKing sending bursts of messages at 20ms with a rolling counter in the message data. Which allows me to easily see if recent or stale data is received.
    Thanks for your help.
    Zia