CAN bus: What faults will increment the Transmission Error Counter - Page 1
Forum section: electronics / projects

author: AndersJ
author_rank: Frequent Contributor
timestamp: April 03, 2016, 05:48:19 pm
content: I have a CAN bus system that generelly works well.But,when traffic intensity increases I get TEC > 96, which generates transmitter warning interrupts.I realize I may have bandwidth problems.But I would like to better understand what causes the transmission errors.My question therefore is:- Which are the primary reasons for transmission errors?

author: Jeroen3
author_rank: Super Contributor
timestamp: April 03, 2016, 06:00:31 pm
content: Chapter 6 & 7:http://www.bosch-semiconductors.de/media/ubk_semiconductors/pdf_1/canliteratur/can2spec.pdfDo you have a CAN analyzer you can use withBUSMASTERto get some numbers on bus load and error count?Error I encounter the most are bit errors and missing acknowledge. Sometimes someone removed a node but forgot to put the termination resistor back on. But this can be easily seen with an oscilloscope, reflections will be all over the place.

author: AndersJ
author_rank: Frequent Contributor
timestamp: April 03, 2016, 07:08:17 pm
content: Thanks for the BUSMASTER suggestion.I downloaded and ran it with my Ixxat interface.I like the network statistics.That feature may help explain my issues.I do however have some doubts about how it measures the average load.The load stays around 99% most of the time even with a low message rate of 11 msg/s.At 150 msg/s the average load is 99,85%The baudrate is 100 kb/s.The number of errors are 0.Could I have collisions and retransmissions that occupy the bus,that BUSMASTER and I can't see?

author: Niklas
author_rank: Frequent Contributor
timestamp: April 03, 2016, 08:17:20 pm
content: 99% indicated bus load is not a good start. If we start by doing some basic calculations to see where we are first:100 kBaud => 10us/bitA standard id frame uses about 114 bits, given that no stuff bits were added and the needed bus idle time after the frame is included. An extended id uses 132 bits with the similar setup.11 msgs with extended id => 11 * 132 * 10us = 14.5 ms, < 2% bus load150 msgs with extended id => 150 * 132 * 10us = 198 ms, approx. 20% bus loadBased on those estimates, I think we need to look a bit closer on the system itself.How many nodes do you have on the bus?If you have several identical nodes, do they try to transmit frames with identical ids?What kind of oscillator do you have in the nodes?Location: On the desk in the lab, home automation in several rooms, vehicle?Hardware filtering, such as common mode choke, capacitors etc?What is the total cable length between the two nodes that are furthest apart?Power supply stability for the transceivers?

author: Jeroen3
author_rank: Super Contributor
timestamp: April 04, 2016, 06:11:19 am
content: 99% busload but only 11 mgs/s means all the other messages are error frames. But you would have noticed.I think only a small percentage is correctly acknowledged, and the nodes that do not get acknowledged (filters?) keep re-transmitting.

author: matkar
author_rank: Regular Contributor
timestamp: April 04, 2016, 06:50:33 pm
content: Niklas already pointed this out by asking but I'll mention it here anyway.Back in time I had a weird problem. I was testing a network by having two identical nodes sending packets to each other periodically. A few tens of packets per second. After a while the bus became fully loaded and no packets were received by any of the nodes. What happened was the two transmitters synchronized and since they were sending identical packets neither could see it and the arbitration never occurred.Never send identical packets. Always make sure the nodes send unique packets (usually enforced by using a node address in higher level protocols).

author: Jeroen3
author_rank: Super Contributor
timestamp: April 04, 2016, 07:44:50 pm
content: Yes, nodes that transmit identical frame ID's will cause you trouble.Since there will be a bit errors after the arbitration field each time they transmit simultaneously, and I do not recall CAN bus using pseudo-random retransmit delays. They will just try again until they bus-off.

author: AndersJ
author_rank: Frequent Contributor
timestamp: October 10, 2016, 06:31:54 pm
content: Is there a reliable way to detect the lost arbitration situation?Preferably followed by a transmission abort,and even more preferable,also followed by a retransmission without loosing packets?

author: cat87
author_rank: Regular Contributor
timestamp: October 11, 2016, 10:31:11 am
content: QuoteBecause the packet arbitration is handled by the transceiver chip, you actually have to hook a logic analyzer or scope to the bus and see what actually is happening. The Node that sends to the smallest address has priority. So, a node that's sending to 0x01 for example will always win against another node sending to 0x05.Such a high bus load does indeed mean that there are error frames on the bus. However, an "error frame" is actually either a frame that was not acknowledged (maybe CANH and CANL are reversed?) or there are multiple nodes that try to transmit to the same ID.So basically, if you want to get to the bottom of this, I'd suggest hooking a scope / LA and actually see what is happening on the bus. In the case you're hooking an LA, hook it up to the CANL only. the software should be able to make sense of things, if you turn on CAN decoding.Also, when doing this, remember that the default CAN bus state is recessive. So the first node that puts a dominant state on the bus wind the arbitration. Try and be on the watch for anything weird regarding this.

author: AndersJ
author_rank: Frequent Contributor
timestamp: October 11, 2016, 11:01:08 am
content: Thanks for your suggestions.My question however concerns whether or not it is possible toperform a graceful runtime recovery from a loss of arbitration,caused by two simultaneous transmission attempts of packetswith identical identifiers.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 11, 2016, 11:32:33 am
content: Quote from: AndersJ on October 11, 2016, 11:01:08 amAFAIK, it's not possible. You must design the system so that the two devices do not try to send with the same ID. For example, ID should be designed to uniquely identify what the data is, and if multiple devices are designed to send the same type of data, you also include a field telling where the data is coming from.

author: AndersJ
author_rank: Frequent Contributor
timestamp: October 11, 2016, 05:46:45 pm
content: I believe thatonlythe 11/29 bit CAN identifier is used for arbitration?A forum post somewhere mentioned that the 0-8 byte payload is also included,implying that a unique payload may be used to resolve arbitration issues.Is this true?

author: Niklas
author_rank: Frequent Contributor
timestamp: October 11, 2016, 11:00:12 pm
content: Only the identifier is used for the arbitration. However, if two nodes begin to transmit frames with exactly same identifier, perfectly synchronized in time, but with different data, then the node that detects that its transmitted data does not match will abort the transmission and issue an error frame. The result is then that none of the two competing nodes will win and both will have to start over from arbitration again after a short delay. The situation can unlock itself if the competing nodes have different delays until they try to retransmit.

author: AndersJ
author_rank: Frequent Contributor
timestamp: October 12, 2016, 02:28:37 am
content: Are you saying that:- Only ONE node will transmit the error frame- The error frame will be transmitted without (collisions or other) errors- The error frame can be detected by the "other" device" which can thenabort its unsuccessful transmission and possibly retry after a delay,long enough for the "first" one to successfully retransmit its previously unsuccessful packet.Can the "short delay" you mention above be configured so that one controller will waita bit longer than the other, thus ensuring that the next arbitration will be successful?How are error frames normally handled when they are received/detected?Is it a fundamental design flaw to even allow identical identifiers?On the other hand, shit happens wherever Murphy works,and he is a frequent contributor in my lab,so I would appreciate if there is a recommended way to resolve this.How are these arbitration errors normally resolved?

author: C
author_rank: Super Contributor
timestamp: October 12, 2016, 03:05:45 am
content: http://www.keil.com/download/files/can_primer_2009sp.pdfhttp://www.keil.com/appnotes/files/apnt_236.pdf

author: Siwastaja
author_rank: Super Contributor
timestamp: October 12, 2016, 05:50:16 am
content: Quote from: AndersJ on October 12, 2016, 02:28:37 amAFAIK, using identical identifiers is the fundamental design flaw. CAN bus is defined on rather low level, so I can't see how it could be "not allowed". No one can prevent you from doing this. Your responsibility as a CAN system designer is not to do it.I have never had this kind of issue; I always design the ID fields to have a sender ID, for example. With 31-bit extended IDs, you have quite a lot of address space to use. For example, on my current project, I'm using 6 bits for a device type identifier (if I later decide to connect other nonsimilar devices to the network), 3 bits to configure message priority (urgency), 12 bits for device ID (max. 4096 similar devices on the bus), and finally, 8 bits for the message type.

author: Niklas
author_rank: Frequent Contributor
timestamp: October 12, 2016, 09:47:16 pm
content: Quote from: AndersJ on October 12, 2016, 02:28:37 amIn this case yes as it is only the transmitting node that see the mismatch between sent data and what is actually on the bus. The other transmitting node, the one that transmitted a dominant bit, will not see the mismatch but it will abort when it detects the error frame.Quote from: AndersJ on October 12, 2016, 02:28:37 amYes. The error frame is not like an ordinary data frame with identifier, header, data and checksum. Instead it is just 6 dominant bits that will trash whatever data is sent on the the bus.As CAN combines both clock and data in the same signal there must be some way to synchronize all the nodes from drifting and possible out of sync issues. To do this, there is a demand for maximum 5 consecutive bits of the same polarity transmitted on the bus. In case you want to send 0b00000000, the CAN controller automatically inserts a stuff bit with reverse polarity so the bus data will be 0b000001000 (9 bits instead of 8 ). The error frame will violate this demand and that is also how it can be identified inside an ordinary data frame.Quote from: AndersJ on October 12, 2016, 02:28:37 amYesQuote from: AndersJ on October 12, 2016, 02:28:37 amIn theory yes, but it depends also on the CAN controller and its possible configurations.Quote from: AndersJ on October 12, 2016, 02:28:37 amThe transmitting node aborts, waits and will retry.The receiving nodes will scrap the partially received messageQuote from: AndersJ on October 12, 2016, 02:28:37 amYes. If you have a network with 20 identical sensors, how are you going to link the received data to a specific sensor?