LPC11Cxx CAN Controller Automatic Retransmission - TEC

[lpcware]

Content originally posted in LPCWare by yilmazkircicek on Tue Apr 22 01:05:57 MST 2014
Hi All,

We are trying to desing an CANopen node with LPC11C14.

Automatic Retransmission is active as required by standard.

But I have seen this unexpected behaivior while testing.

1. I have remove the can bus connector.
2. Then power the device
3. My device tries to transmit firt message (Boot-Up) as usual. But there is no any device on bus to ACK.
4. So my device increase TEC by 8 as expected.
5. After 16 attemp controller turn the Error Passive condition as expected.
6. But automatic transmission is stopped then. This was unexpected ! It should try untill BUS OFF condition. Should not it ?

Is there a attempt limit for automatic transmission ? Is it disabled in Error Active condition ?

Best Regards.

[lpcware]

Content originally posted in LPCWare by ErikC on Wed Oct 08 08:00:15 MST 2014
Hi all,

All these info are relevant for me and I understand what to take into account. I encountered the following issue:

A CAN server sends a common request to all nodes (using a common ID) for getting a IO status like buttons, temperature. All nodes are able to send a response individually but there are some conflicts on the CAN bus. With thank to the retransmission mechanism, it is solved. However after a while (e.g. 10 times common requests), the nodes with highest ID are put into BUS OFF state due to high value on TEC (0xFD). I have added a part in the CAN error ISR handler that will clear the bit 0 of CANCTRL (INIT). I thought it will solve the TEC overflow issue. However it will cause a bus overload with a consequence that the CAN system is down.

Who can point me out how to solve this issue? Or should I always work with individual requests for getting status from each node?

Note: the quality of signals on CAN bus is ok at 500kHz.

Erik 

[lpcware]

Content originally posted in LPCWare by yilmazkircicek on Thu Apr 24 04:13:17 MST 2014
Dear R2D2,

I have asked the question regarding automatic re-transmission and cyclic message period issues to CIA especially for the CANopen.
As you know one node can be error passive while other communicating. Consider a node has a cyclic PDOs with 1ms period, auto re-transmission is activated during error passive condition.
Here is a part of the answer;

CANopen is an application layer, that utilizes CAN as it is. For CANopen nothing has to be "switched off" and nothing will be "switched off".
......
To make the story short: don't care about that problem. People who use it, will have other problems anyhow.

Our device is a slave and slaves always obey master's directions, even if it requires being a babling idiot.
But master give a means for the solutions : Object 1029h: Error behavior object for CANopen
You can be kind and want to solve the problem but only obeying to rules. Because anyone can have different level of kindness attitude and perception.

According to list below, 0x80 is appropriate for applying your advice.

I thank you for the short convesation and sharing experience.

Best Regards.

[img]http://i.hizliresim.com/glyQW3.jpg[/img]

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu Apr 24 01:25:10 MST 2014

---

Quote: yilmazkircicek
Why do we design so kind ?

---

Because I draw / test / use a lot of nodes and don't like nodes which panic early  :bigsmile:

So I prefer a more polite communication without filling the bus with retransmissions.

Instead a behaving like a babbling idiot they can try to solve the problem or just give other nodes time to solve their problems...

[lpcware]

Content originally posted in LPCWare by yilmazkircicek on Wed Apr 23 09:34:39 MST 2014
I decide to use brutal force to the communication channel and use all the rights to the utmost given by ISO11898-1

What ISO11898-1 says;

- Use auto re-transmitting (exceptional TTCAN)
- Lack of ACK is a reason for unsuccesful transmission
- I have right to transmit if I won arbitration
- I have right to transmit in error passive condition.

Why do we design so kind ? I will not do anything conflicting with standard ? Do the asked us while ruling the standard ?

Designers can be bona fide but standart bodies are not. All of the communicaition protocols have bottlecks. (including speaking, especially with women)

I will try it with CIA CANopen conformance test tool to see what happens.

Best Regards.

[lpcware]

Content originally posted in LPCWare by R2D2 on Wed Apr 23 07:29:51 MST 2014

---

Quote: yilmazkircicek
CAN controller is very selfish. It knows there is problem on bus, but keep transmitting :)

---

I would rather call it frantic  :bigsmile:

After enabling SIE in CANCNTL, CAN error handler is a good place to catch error-passive and calm the node.

With DAR, disabling the usual messages and enabling a periodic test message...

BTW: If receiving no ACKs would stop all transmissions the first (or fastest) node could cease communication after power up before another node is ready   :O

[lpcware]

Content originally posted in LPCWare by yilmazkircicek on Wed Apr 23 05:45:17 MST 2014
Dear R2D2,

I thank you for your answer.

Disabling automatic re-transmission seem reasonable. Because there is an ambiguity,
TEC increases by 8 while REC increases by 1 to isolate node having transmit problem as soon as possible.
But TEC stop increasing after 128 if error source is ACK. Nevertheless controller attemp to retransmit and disturbing the bus.
CAN controller is very selfish. It knows there is problem on bus, but keep transmitting :)

Best regards.

[lpcware]

Content originally posted in LPCWare by R2D2 on Wed Apr 23 02:45:08 MST 2014

---

Quote: yilmazkircicek
It should try untill BUS OFF condition. Should not it ?

---

As you figured out already, disconnecting a node is not and should not switch the bus off. Without receiving ACKs the node should stop at error passive to be able to accomplish a simple self recovery after reconnecting the node.

If your node didn't stop there was probably another error.

I usually recommend to disable auto retransmission if error-passive is reached.

Something like:

---

Quote:

LPC_CAN0->CNTL |= CTRL_INIT;
LPC_CAN0->CNTL |= CTRL_DAR;
LPC_CAN0->CNTL &=~CTRL_INIT;

---

So there's more time to solve temporary problems...

[lpcware]

Content originally posted in LPCWare by yilmazkircicek on Wed Apr 23 00:46:15 MST 2014
Dear Wouter,

The same issue is still exist. I have also test this and seen that automatic re-transmissiton does not stop but only TEC stop increasing after 128 for no ACK situation.

1. I have removed the bus cable and power cable.
2. Powered up the device, and TEC reached to 128.
3. I have pluged the bus cable, device transmitted the firs message successfully.,

But I have realised that the stuation that I defined as unexpected was actually an expected behaviour.

TEC does not increase in some certain error conditions. I could not find it in NXP documentations but I have seen it in another vendor CAN controller document. It says.

The transmit error counter does not change in the following cases:
• When the transmit unit while in an error-passive state has detected an ACK error for reasons that ACK was not detected and has detected no dominant levels while sending a passive-error flag.
• When the transmit unit has encountered a stuffing error during arbitration (dominant level is detected although it transmitted a recessive level as bit stuffing).

After all that all that I can not explain the statemant below. You are completely right, it seem impossible. I tried but could not create the same stiation again. I think that is the fishy one.
Maybe I should take a break.

---

Quote:
As a note: When I test it by removing the CAN bus connector, it tries to retransmit the same mesage object (eg . NMT Boot-up) 16 times then TEC does not increase any more. If I try to transmit
another message after TEC = 128, it increases to 255 and goes to BUS OFF condition.

---

Now I have no problem now Thank for your support and time.

Best Regards.

[img]http://i.hizliresim.com/ydRlMj.jpg[/img]

[lpcware]

Content originally posted in LPCWare by Wouter on Tue Apr 22 16:22:48 MST 2014
Hi Yilmaz,

In your first post you mention the message is not put on the bus anymore after 16 tries. You mention this does not seem right (which I agree, that's not the right behavior). In your second post, I do not see this statement any more. Is this issue still present?

Furthermore:

---

Quote:
I want to test it with different way, I configured the CANopen master (an IXXAAT module) and my device with different bit rates, say 125kbps and 500kbps. This time it goes to BUS OFF condition as expected but I am not sure about the reason. (TX, stuff, ACK etc.) I should have to check it. Now it is 23:50 in Turkey and tomorrow I will debug it.

---

That seems right, any fault other than no ack received would increase TXERR >0x80, and result eventually in BUSOFF.

---

Quote:
As a note: When I test it by removing the CAN bus connector, it tries to retransmit the same mesage object (eg . NMT Boot-up) 16 times then TEC does not increase any more. If I try to transmit another message after TEC = 128, it increases to 255 and goes to BUS OFF condition.

---

This also does not sound right to me. AFAIK an un-acknowledged message should not be able to bring TXERR >0x80, also not when sending two messages which are not being acknowledged.

To me it sounds like something fishy is going on on your board/SW...

Regards,
Wouter

[lpcware]

Content originally posted in LPCWare by yilmazkircicek on Tue Apr 22 14:02:10 MST 2014
Dear Wouter,

I thank you for your interest.

Board is custom and CANopen stack is written from the scratch.
Both board and firmware works fine. I was testing it before compliance application to CIA


I wonder how it behaves on error conditions. Easiest make an error is removing the connector.

As you can guess, a successfull transmission should be acknowled by the other node.  If there is no any device on bus LPC11C14 CAN controller attemting to transmit 16 times until TEC is equal to 128. (Auto re-tranmission is active) LEC is clearly shows that ACK error for every attempt.

I want to test it with different way, I configured the CANopen master (an IXXAAT module)  and my device with different bit rates, say 125kbps and 500kbps. This time it goes to BUS OFF condition as expected but I am not sure about the reason. (TX, stuff, ACK etc.) I should have to check it. Now it is 23:50 in Turkey and tomorrow I will debug it.

As a note: When I test it by removing the CAN bus connector, it tries to retransmit the same mesage object  (eg . NMT Boot-up)  16 times then TEC does not increase any more. If I try to transmit another message after TEC = 128, it increases to 255 and goes to BUS OFF condition.

This only happens with ACK error. (eg no CANBUS cable connection)

Best Regards.

[lpcware]

Content originally posted in LPCWare by Wouter on Tue Apr 22 09:42:50 MST 2014
Hi Yilmaz,

This indeed should not happen.
Are you sure your CAN connection is OK (e.g. termination resistor is present)?

Can you comment what software and which board you're using?
It works fine on the LPCOpen example running on the MCB1000 and LPCXpresso LPC11C14 board

Regards,
Wouter