Clarification of MultiCan handling of transmission failure

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
In the reference manul for XMC45, figure 18-18 shows the transmission of a message object. According to the figure, the transmission is aborted and no interrupt is generated if transmission was not successful.

Questions:
1. Under what circumstances can the transmission fail?
2. If no interrupt is generated if transmission fails, then how is one to know that buffer is no longer in use by hardware?
0 Likes
3 Replies
DRubeša
Employee
Employee
First solution authored First like received
Hi Fredrik,

I would suggest to you that you take a look at the Table 18.7. There you will find the encoding for Last Error Code (LEC). These are common causes of the transmission fail scenario. LEC bitfield (which is part of NSRx (where "x" is the CAN node number) register) will hold the error code that caused transmission failed.

In Figure 18-9 (CAN NOde Interrupts) you can see that it is possible to have interrupt event triggered once LEC value changes, meaning you can easily see that you´re transmission failed and you can easily detect the cause.
Other approach would be to enable the interrupt event once the TXOK bit was set, meaning transmit was successful, other CAN node acknowledged received message object, so there wasn´t any error in the transmission.

Best regards,
Deni
0 Likes
Not applicable
Thanks for the reply!

I've done some exprerimentation, and it seems like the LEC interrupt is tiggered each time a single (re)transmission attempt fails. As frames are retransmitted, this is just a temporary error. For example, if I start a transmission with no other node on bus, I get an ACK error. When I later bring a node on bus, the frame is retransmitted successfully and the Tx interrupt is triggered.

What I want to know is if there is any way that hardware will truly abort the transmission, given that "Single Data Transfer Mode" and "Single Transmit Trial" are both OFF?
0 Likes
DRubeša
Employee
Employee
First solution authored First like received
Hi Fredrik,

you may always check the NECNTx (where "x" is CAN Node number) register. There you can see the TEC (Transmit Error Counter) and REC (Receive Error Counter) bitfields. If the CAN module detects an error while the transmit operation is running, TEC bitfield value will be incremented by 8 or by 1 (for more details please refer to 18.3.4. Error Handling Unit chapter). Why this value is interesting for you? Well, if the value in the TEC or REC bitfield exceeds 128, then CAN node goes to error-passive state meaning no other re-transmissions will be attempted. Exactly on the error that you mentioned (no other CAN node in the CAN network), I´ve experienced TEC value reaching 0x80 (128) and then CAN node stops transmitting because it sees there is no other CAN node to acknowledge the message object. There is also additional bitfield that may interest you; NECNTx.EWRNLVL. You can set the threshold error level after which NSRx.EWRN bit will be set. This bit can be then used to trigger the interrupt to notify you "hey I´ve tried to send the message object n_times and I was unsuccessful".

Regarding your question, I would suggest that you try to clear some of the bits that are mandatory for the transmission. I´m now referring to the table 18.18. Try sending your message and once the LEC interrupt occurs in the interrupt handler try to reset either MSGVAL, TXRQ, TXEN0 or TXEN1. I´m not sure this will work, while it maybe be too late and hardware has already "made" decision to transmit the message object but flowchart 18.18 suggest that mentioned bits should be continuously valid.

Try something like this and let me know how it went.

Best regards,
Deni
0 Likes