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: CAN: Problem receiving RTR frames only

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello,

I would like to setup a CAN mailbox to receive RTR frames only but it looks like the device receives both, RTR and DATA frames.

I configured mailbox 1 for reception of RTR frames (but with no auto-response), CAN ID = 0x707, use ID filter for all identifier bits.
DLC is set to 1 for the intended response DATA frame:

CAN_setupMessageObject(
    CANB_BASE,
    1,
    0x707,
    CAN_MSG_FRAME_STD,
    CAN_MSG_OBJ_TYPE_TX_REMOTE,
    0x7FF,
    CAN_MSG_OBJ_USE_ID_FILTER,
    1
);


I check for received RTR frames, clear the 'New Data' bit by reading the RTR message and then send the response message:

uint8_t responseData[8]; // initialized with zeroes

if (CAN_getNewDataFlags(CANB_BASE) & 0x00000001))
{
    uint8_t dummy[8];
    CAN_readMessage(CANB_BASE, 1, dummy);
    CAN_sendMessage(CANB_BASE, 1, 1, responseData);
    
    responseData[0] ^= 0x80; // toggle upper bit for each response message being sent
}


As long as RTR frames are being received, the above procedure works well.
(incoming frame is successfully detected, response DATA frame is sent as expected)

The problem arises when DATA frames (with the same CAN ID) are being received.
It looks like it does not only listen to RTR frames but also to DATA frames.

In case of DATA frames the above procedure turns into a strange behaviour:
* The DATA frames are recognized and can be received
* Executing the 'CAN_sendMessage' does now send an RTR frame instead of a DATA frame (why??)

My question:
Is it possible to setup a mailbox to listen to RTR frames only?
(I would like to accept RTR only and drop/ignore DATA frames for this mailbox)

The used C2000Ware is version 3.04.00.00.

Thank you,
Markus

  • Hi Markus,

    Like you hinted at, my first recommendation would be to do software filtering (check and only react to RTR frames). 

    Before going further though, is there a use case where receiving RTR frames on the same ID as non RTR frames? Could two IDs be used instead (one for RTR and one for non RTR)?

    EDIT: Typos and clarification below.

    I am mainly sanity checking the possibility of two IDs for different frame types since that seems to be more common. By going with two IDs we circumvent the issue altogether.

    Regards,

    Vince

  • Hello Vince,

    thank you for the quick reply.

    How is it possible to check if the received frame is a RTR or DATA frame on this device?
    I have checked the mailbox registers (CMD, MSK, ARB, MCTL) and they does not seem to contain a bit (or element) to check whether the last received frame was RTR or DATA.

    I have found just 1 bit which is RTR related, "RmtEn" in register "MCTL".
    But this bit just does decide, if the Transmit request is set in case of an RTR frame reception.

    AFAIK there is no such use case to receive RTR and DATA with the same identifier.
    My intention is to use RTR reception only.

    Regards,
    Markus

  • Hi Markus,

    What I am meaning by use case for RTR and DATA with same identifier is can you enforce that whichever device(s) send the message to that ID, that it only sends RTR?

    Basically, it sounds like a device is sending both RTR and DATA with the same identifier. Can you enforce in the system that it doesn't do that?

    Regards,

    Vince