ECAN message priority

Hi All,

I have the same problem:

It appears that if lower priority MBOXs are triggered first but are pending, they are delaying the high priority message.

I am running a 500kHz CAN network with 4 nodes consisting of 28335 micros. The bus time average usage is around 50%. All messages use std 11 bit identifiers.

Node 1 emits the following messages

COB_ID=0x241,  MBOX=17,  TPL=26(highest),  TX_RATE=2mS (time critical, on SYNC)

COB_ID=0x2C1,  MBOX=23,  TPL=25,  TX_RATE=asyncronous (on event)

COB_ID=0x4C1,  MBOX=26,  TPL=23 (lowest),  TX_RATE=5mS

There are other nodes on the bus transmitting many messages, meaning that all messages can have to wait to send.

COB_ID=0x241 is usually sent at the correct rate, but occasionally it gets delayed by the transmission of COB_ID=0x2C1 or COB_ID=0x4C1. Sometimes I see that also COB_ID=0x2C1 is sent after COB_ID=0x4C1.

Thank you,

Demis

Well, you're using mailboxes 16 and above, so I guess the answer is yes. :-)

This behavior is expected. The 2833x eCAN reference guide (lit number sprueu1) describes what's going on in section 1.3:

When a message must be transmitted, the message controller transfers the message into the transmit
buffer of the CPK [CAN Protocol Kernel] in order to start the message transmission at the next bus-idle state. When more than
one message must be transmitted, the message with the highest priority that is ready to be transmitted is
transferred into the CPK by the message controller. If two mailboxes have the same priority, then the
mailbox with the higher number is transmitted first.

So the prioritization is done when the CPK is loaded, not when the message is actually transmitted.

Hi Adam,

I did other tests and found the same problem.

I am running a 500kHz CAN network with 32 nodes consisting of 28335 micros and a CANopen master (with a different CPU).
The bus time average usage is around 77%.
All messages use std 11 bit identifiers.

Node in the range 1-16 can send the following messages

COB_ID=0x240+NodeId,  MBOX=17,  TPL=26(highest),  TX_RATE=6ms (time critical, on SYNC)

COB_ID=0x2C0+NodeId,  MBOX=23,  TPL=25,  TX_RATE=asyncronous (on event)

COB_ID=0x4C0+NodeId,  MBOX=26,  TPL=23 (lowest),  TX_RATE=asyncronous (on event)

(i.e.
node 1 sends PDO 0x241, 0x2C1, 0x4C1;
node 2 sends PDO 0x242, 0x2C2, 0x4C2;
....
node 16 sends PDO 0x250, 0x2D0, 0x4D0)

I recorded some logs of CPU register content and of messages in the network (with a CANopen sniffer).

I reproduced the following situation many times.

Focus attention on node 7.

- A SYNC is sent by the master and it is received by node 7.

- Node 7 writes PDO 0x247 in MBOX 17 and then sets bit 17 in CANTRS to emit PDO in the network.

- CAN module tries to emit PDO 0x247 in the network for about 500 microseconds without success because in the network there are other messages with higher priority (PDO 0x241, 0x242, 0x243, ecc. sent by node 1, 2, 3, ecc.).
I think that CAN module is trying to emit PDO 0x247 but it fails because of LOSS OF ARBITRATION.
In fact I see many double transitions of TM bit in CANES register: TM bit goes high (CAN module is transmitting) and after few microseconds TM goes low (CAN module is not transmitting). I think that each double transition is a loss of arbitration, isn't it?.

- After 500 microseconds Node 7 writes PDO 0x2C7 in MBOX 23 and PDO 0x4C7 in MBOX 26 and then sets bits 23 and 26 in CANTRS to send PDOs out to the network.
In this moment mailboxes 17, 23 and 26 have all a PDO to emit (0x247, 0x2C7, 0x4C7, respectively).

- After 300 microseconds Node 7 succeeds in emitting PDO 0x247 in the network.
In this moment mailboxes 23 and 26 have a PDO to emit (0x2C7, 0x4C7, respectively).

- After 2 milliseconds Node 7 succeeds in emitting PDO 0x2C7 in the network.
In this moment only mailbox 26 has a PDO to emit (0x4C7).

- After 3 milliseconds a new SYNC message is received and node 7 writes PDO 0x247 in MBOX 17, then sets bit 17 in CANTRS to emit PDO in the network.
In this moment both mailbox 17 and 26 has a PDO to emit (0x247, 0x4C7, respectively).

- CAN module tries to emit a PDO (WHICH?! 0x247 or 0x4C7?) for more than 6 milliseconds (!!!) without success.
During this long time I see many double transitions of TM bit in CANES register (as described above). I think that each double transition is a LOSS OF ARBITRATION.

However, in the network I log this sequence of messages with the CAN sniffer:
0x241, 0x242, 0x243, 0x244, 0x245, 0x246, 0x2C1, 0x2C2, 0x2C3, 0x2C4, ecc.

Therefore I expects that after PDO 0x246 node 7 can emit PDO 0x247 in the network, on the contrary I don't see it but I see PDO 0x2C1, 0x2C2, 0x2C3, ecc.
I presume that node 7 is trying to emit PDO 0x4C7 instead of PDO 0x247 even if PDO 0x4C7 has lost arbitration many times.

So it seems to me that CAN module doesn't check if there is other mailbox with higher priority to emit even if a loss of artitration has occurred.
 
Thank you in advance for any suggestions.

Demis,

Consider the time interval indicated by <-*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/-->

- After 2 milliseconds Node 7 succeeds in emitting PDO 0x2C7 in the network.
In this moment only mailbox 26 has a PDO to emit (0x4C7).
                   <-*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/-->

- After 3 milliseconds a new SYNC message is received and node 7 writes PDO 0x247 in MBOX 17, then sets bit 17 in CANTRS to emit PDO in the network.
In this moment both mailbox 17 and 26 has a PDO to emit (0x247, 0x4C7, respectively).

After PDO 0x2C7 is successfully transmitted, PDO 0x4C7 is loaded into the transmit buffer, which can hold only one frame at a time. So, even though node 7 writes PDO 0x247 in MBOX17, PDO 0x4C7 goes out first since it has already been copied into the transmit buffer.

Hareesh J said:

Demis,

Consider the time interval indicated by <-*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/-->

- After 2 milliseconds Node 7 succeeds in emitting PDO 0x2C7 in the network.
In this moment only mailbox 26 has a PDO to emit (0x4C7).
                   <-*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/-->

- After 3 milliseconds a new SYNC message is received and node 7 writes PDO 0x247 in MBOX 17, then sets bit 17 in CANTRS to emit PDO in the network.
In this moment both mailbox 17 and 26 has a PDO to emit (0x247, 0x4C7, respectively).

After PDO 0x2C7 is successfully transmitted, PDO 0x4C7 is loaded into the transmit buffer, which can hold only one frame at a time. So, even though node 7 writes PDO 0x247 in MBOX17, PDO 0x4C7 goes out first since it has already been copied into the transmit buffer.

Hareesh,

thank you for your reply.

I understand that PDO 0x4C7 has been loaded into the transmit buffer before PDO 0x247 is loaded into MBOX 17. But during the next 6 milliseconds after PDO 0x247 has been loaded into MBOX 17, the CAN module tries to emit PDO 0x4C7 without success many times, because there are messages with higher priority in the network (PDO with COB-ID 0x2C1, 0x2C2, 0x2C3, 0x2C4, ecc.).
Therefore I presume that during that 6 ms the CAN module of node 7 has lost arbitration many times.

The 2833x eCAN reference guide (lit number sprueu1) describes the behaviour of CAN module in section 1.5.1:

"If a transmission fails due to a loss of arbitration or an error, the message transmission will be
reattempted. Before reattempting the transmission, the CAN module checks if other transmissions are
requested and then transmits the mailbox with the highest priority."

So, I know that PDO 0x4C7 has been loaded into the transmit buffer, but I expect that after a loss of arbitration PDO 0x247 should replace PDO 0x4C7 into the transmit buffer and should be emitted before PDO 0x4C7, according to eCAN reference guide.

On the opposite, it seems to me that CAN module doesn't check if other transmissions are requested when there is a loss of arbitration. From my point of view this is the heart of the problem.

I hope to have been clear enough in explaining the issue.

Demis

Hareesh,

Thank you very much. I got the CAN package working now. I appreciate the time you spent instrucing  me.

Regards,

Nolan

Nolan,

 I am afraid you responded on the wrong thread :-). Could you please respond on https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/448678/1615442#1615442 and also tell us what was wrong with your setup?

Demis,

Sorry for the delayed response. I have some update for you. All along, my focus was on the transmit-buffer (TB). I was under the impression that once the data was moved to the transmit-buffer, it will go out regardless of the situation where arbitration was lost (for the frame in the TB) AND even if higher priority messages are pending transmission. We looked into the design and ran some simulations and what we found is that it does not matter data has been moved to the TB.

• As long as the higher-priority TRS is set before the message in the TB has lost arbitration, the higher priority MBX will be transmitted after the current message in TB has lost arbitration.
• However, if the higher-priority TRS is set after the message in the TB has lost arbitration, the higher priority MBX will be transmitted only after the current message in TB has transmitted.

SEGNALAZIONE TEXAS 2
21/10/2015

Hareesh,
thank you very much for your assistance.
I forwarded your reply to other members of my project team and we discussed it.

To be sure to have understood your reply we'd like submitting you two more situations.

The conditions of CANopen network are the same of my previous posts:

I am running a 500kHz CAN network with 32 nodes consisting of 28335 micros and a CANopen master (with a different CPU).
The bus time average usage is around 77%.
All messages use std 11 bit identifiers.

Node in the range 1-16 can send the following messages

COB_ID=0x240+NodeId,  MBOX=17,  TPL=26(highest),  TX_RATE=6ms (time critical, on SYNC)

COB_ID=0x2C0+NodeId,  MBOX=23,  TPL=25,  TX_RATE=asyncronous (on event)

COB_ID=0x4C0+NodeId,  MBOX=26,  TPL=23 (lowest),  TX_RATE=asyncronous (on event)

(i.e.
node 1 sends PDO 0x241, 0x2C1, 0x4C1;
node 2 sends PDO 0x242, 0x2C2, 0x4C2;
....
node 16 sends PDO 0x250, 0x2D0, 0x4D0)


Focus attention on node 7.

SITUATION 1
- Node 7 writes PDO 0x4C7 in MBOX 26 and then sets corresponding TRS. The message is transferred to TB but it doesn't go out to the net because network is already occupied by another message (for instance 0x4CB sent by node 11).
  Till this moment NO loss of arbitration occurred inside node 7 because TB hasn't tried to emit any message.
    
- Node 7 writes PDO 0x2C7 in MBOX 23 and then sets corresponding TRS.
  The message stays inside MBOX 23 because TB is occupied by PDO 0x4C7.
    
- When network becomes free node 7 tries to emit TB message (that is PDO 0x4C7), however it fails because node 3 is trying to emit PDO 0x243. Therefore node 3 wins while node 7 loses arbitration (FIRST ARBITRATION LOSS).
Just because of this arbitration lost, CAN module checks other MBOX and finds that MBOX 23 has a message with higher priority, so PDO 0x2C7 is transferred to TB.

- When network becomes free again node 7 tries to emit TB message (now it is PDO 0x2C7) etc.


SITUATION 2
- Node 7 writes PDO 0x4C7 in MBOX 26 and then sets corresponding TRS. The message is transferred to TB but it doesn't go out to the network because network is already occupied by another message (for instance PDO 0x4C9 sent by node 9).
  Till this moment NO loss of arbitration occurred inside node 7 because TB hasn't tried to emit any message.

- When network becomes free node 7 tries to emit TB message (that is PDO 0x4C7), however it fails because node 3 is trying to emit PDO 0x243. Therefore node 3 wins while node 7 loses arbitration (FIRST ARBITRATION LOSS).

- After that, Node 7 writes PDO 0x2C7 in MBOX 23 and then sets corresponding TRS.
The message stays inside MBOX 23 because TB is occupied by PDO 0x4C7.

- When network becomes free node 7 tries to emit TB message (that is PDO 0x4C7), however it fails because node 5 is trying to emit PDO 0x247. Therefore node 5 wins while node 7 loses arbitration again (SECOND ARBITRATION LOSS).
According to your latest reply, CAN module DOESN'T check other MBOX and mantains PDO 0x4C7 inside TB.

- When network becomes free node 7 tries to emit TB message (that is PDO 0x4C7), however it fails because node 2 is trying to emit PDO 0x2C2. Therefore node 2 wins while node 7 loses arbitration again (THIRD ARBITRATION LOSS).
Like previously CAN module DOESN'T check other MBOX and mantains PDO 0x4C7 inside TB.

- When network becomes free node 7 tries to emit TB message (that is PDO 0x4C7), however it fails because node 6 is trying to emit PDO 0x2C6. Therefore node 6 wins while node 7 loses arbitration again (FOURTH ARBITRATION LOSS).
Like previously CAN module DOESN'T check other MBOX and mantains PDO 0x4C7 inside TB.

- After that, node 7 writes PDO 0x247 in MBOX 17 and then sets corresponding TRS.
The message stays inside MBOX 17 because TB is occupied by PDO 0x4C7.

- When network becomes free node 7 tries to emit TB message (that is PDO 0x4C7), however it fails because node 4 is trying to emit PDO 0x2C4. Therefore node 4 wins while node 7 loses arbitration again (FIFTH ARBITRATION LOSS).
Like previously CAN module DOESN'T check other MBOX and mantains PDO 0x4C7 inside TB.

- When network becomes free node 7 tries to emit TB message (that is PDO 0x4C7) and this time it wins arbitration.

- After completing emission of PDO 0x4C7, CAN module checks other MBOX and transfers PDO 0x247 (highest priority message) form MBOX 17 to TB.

- Then node 7 tries to emit TB message (that is PDO 0x247) to the network, etc.


So my question is: the descriptions of situation 1 and 2 are correct with respect to the behaviour of CAN module?

In other words setting higher priority TRS after a loss of arbitration has no effect, because CAN module tries to emit TB current message anyway, even if other arbitration losses occur after higher priority TRS are set.

Is it true?

If it is true, it seems to me that what it is written in section 1.5.1 of 2833x eCAN reference guide (lit number sprueu1) is not correct:

"If a transmission fails due to a loss of arbitration or an error, the message transmission will be reattempted. Before reattempting the transmission, the CAN module checks if other transmissions are requested and then transmits the mailbox with the highest priority."

On the contrary, the correct description of the CAN module behaviour is the following:
CAN module checks if other transmissions are requested ONLY IF TRS has been set BEFORE the FIRST arbitration LOSS otherwise CAN module doesn't check other MBOX. After first arbitration losses MBOX are checked only after TB current message is emitted to the network, no matter how many arbitration losses occur.

This means that a low priority message (for instance PDO 0x4C7) can prevent a higher priority message (for instance PDO 0x247) to go out in the network.

Is it correct?

Sorry if I have dwelt with these situations but I need to be sure to have understood the real behaviour of CAN module.

Thank you in advance for your attention.

Demis

Demis,

            Here is my analysis:

SITUATION1:

Your understanding is correct. Because TRS23 was set before the arbitration loss suffered by MBX26, MBX23 will be transferred to the TB. It is misleading to say "MBOX 23 has a message with higher priority". It would be correct to say "MBOX 23 has higher priority". Note that priority for MSGID is at the bus level i.e. after the MSGID from multiple nodes are transmitted on the bus. Within the CAN module itself, if TPL values are equal, a higher numbered MBX has priority over a lower numbered MBX. In your case, priority is dictated by the TPL value.

SITUATION2:

I believe your understanding is correct. However, we have not run a simulation for this particular scenario.

I agree the wording in the User Guide needs to be amended.

If you feel it would be more effective, you can reach me directly through our FAE (Mr.Jagla)

Hareesh,
in the following weeks we'll discuss some workarounds for this issue. I think it could be useful for us to reach you directly, if possible. How can we do?

Thank you for your support.

Demis

Demis,

 I am working on facilitating this through the distribution FAE (Sergio Piovella). He is already in touch with the TI FAE.

Ok, thank you very much, Hareesh.

Demis