TMS320F28075: receiving and identifying RTR messages

Demis,

            Not sure why you are setting RmtEn = 0 (i.e. you don’t want an automatic response to remote frame).

As to your question on how to differentiate between a remote-frame Vs a data-frame, I am not very familiar with CANopen but is it a valid use-case for either frame to appear on the bus with the same COB-ID (MSGID)?

Regarding your question about RTR bit, there is no RTR bit-field. See below snippet from TRM:

22.11.2 Configuration of a Transmit Object for Remote Frames

It is not necessary to configure transmit objects for the transmission of remote frames. Setting TxRqst for a receive object will cause the transmission of a remote frame with the same identifier as the data frame for which this receive object is configured.

Hareesh J said:

Demis,

            Not sure why you are setting RmtEn = 0 (i.e. you don’t want an automatic response to remote frame).

I try to explain you with an example.

I use the RTR message for canopen Nodeguard service: the master sends an RTR frame and the slave (node) replies with an 8-bit number that reflects its communication state: 4 = Stopped, 5 = Operational, 127 = Pre-operational.
Moreover the master can change node communication state by sending an NMT message.

Suppose that the slave is in Pre-operational state (= 127) and that there is the following message sequence:

 N     time
 1)  0.0000s    MASTER  ------------- RTR ------------>  SLAVE
 2)  0.0002s    MASTER  <------------ 127 -------------  SLAVE
 3)  1.0000s    MASTER  ------------- RTR ------------>  SLAVE
 4)  1.0002s    MASTER  <------------ 127 -------------  SLAVE
 5)  2.0000s    MASTER  ------------- RTR ------------>  SLAVE
 6)  2.0002s    MASTER  <------------ 127 -------------  SLAVE
 7)  3.0000s    MASTER  ------------- RTR ------------>  SLAVE
 8)  3.0002s    MASTER  <------------ 127 -------------  SLAVE
 9)  3.9999s    MASTER  -- NMT: go to operational --> SLAVE   
10) 4.0000s    MASTER  ------------- RTR ------------>  SLAVE

Message 9 force the slave to switch its state from Pre-operational (= 127) to Operational (= 5).
Message 10 asks for the node state.

However message 10 is received by the slave only 100 microseconds after message 9, so if the slave is processing functions or tasks with an higher priority than canopen communication, message 9 is processed AFTER the reception of message 10.

If nodeguard mailbox is set with RmtEn = 1 the node replies immediately to message 10 with response = 127, because DSP hasn't updated the mailbox data with the correct node state yet.
I.e. the following message is sent

11a) time: 4.0001 s MASTER  <------------ 127 -------------  SLAVE

but the master expects state 5 (= operational) and so it signals an ERROR.

On the opposite if nodeguard mailbox is set with RmtEn = 0 the node can process message 9 BEFORE message 10 (with a little delay): it switches state from Pre-operational (= 127) to Operational (= 5) and THEN sends the response with the correct state to the master:

11b) time: 4.0002 s MASTER  <------------   5 -------------  SLAVE

My english isn't good but I hope I was clear.

I know this is a very unlikely situation but unfortunately it sometimes happens.
 

Hareesh J said:

As to your question on how to differentiate between a remote-frame Vs a data-frame, I am not very familiar with CANopen but is it a valid use-case for either frame to appear on the bus with the same COB-ID (MSGID)?

 No, it isn't a valid use-case, in fact in my question I wrote "Suppose the NMT master INCORRECTLY sends a normal frame (an SDO for instance, or a PDO) with COB-ID = 0x701".
In other words I need to know if the message is an RTR message or a data frame message to recognize correct RTR messages from erroneous data frame messages with the same COB-ID.

Hareesh J said:

Regarding your question about RTR bit, there is no RTR bit-field.

Ok.

Hareesh J said:

See below snippet from TRM:

 

22.11.2 Configuration of a Transmit Object for Remote Frames

It is not necessary to configure transmit objects for the transmission of remote frames. Setting TxRqst for a receive object will cause the transmission of a remote frame with the same identifier as the data frame for which this receive object is configured.

That was clear to me.

But I don't need to send an RTR message but only to recognize when I receive one.

In TRM I found an "RTR" among "control bits" (for instance in TRM spruhm9c, pag. 2072, sec. 21.12.6) so I thought there was a control bit, called RTR bit, that told me if the received message was an RTR frame or a data frame.