Need a practical intro to CAN bus errors?
In this tutorial you’ll learn about the basics of CAN error handling, the 5 CAN bus error types, the CAN
error frame and CAN node error states.
To get practical, we’ll also generate & record CAN errors in 6 experiments.
In this article
- What are CAN bus errors?
- The CAN error frame
- 5 CAN error types
- States & error counters
- 6 practical experiments
- LIN bus errors
- CAN error logging use cases
- FAQ
What are CAN bus errors?
As explained in our simple intro
to CAN
bus, the Controller Area Network is today the de facto standard across automotives and industrial
automation
systems.
A core benefit is the robustness of CAN, making it ideal for safety critical
applications.
Here, it is worth noting:
Error handling is vital to the robustness of CAN.
CAN bus errors can occur for several reasons — faulty cables, noise, incorrect termination, malfunctioning
CAN nodes etc. Identifying, classifying and resolving such CAN errors is key to ensuring the continued
performance of the overall CAN system.
In particular, error handling identifies and rejects erroneous messages, enabling a sender to
re-transmit the message. Further, the process helps identify and disconnect CAN nodes that
consistently transmit erroneous messages.
How does CAN error handling work?
Error handling is a built-in part of the CAN standard and every CAN controller. In other words, every
CAN node handles fault identification and confinement identically. Below we’ve made a simple illustrative example:
- CAN node 1 transmits a message onto the CAN bus — and reads every bit it sends
- In doing so, it discovers that one bit that was sent dominant was read recessive
- This is a ‘Bit Error’ and node 1 raises an Active Error Flag to inform other nodes
- In practice, this means that node 1 sends a sequence of 6 dominant bits onto the bus
- In turn, the 6 dominant bits are seen as a ‘Bit Stuffing Error’ by other nodes
- In response, nodes 2 and 3 simultaneously raise an Active Error Flag
- This sequence of raised error flags comprise part of a ‘CAN error frame’
- CAN node 1, the transmitter, increases its ‘Transmit Error Counter’ (TEC) by 8
- CAN nodes 2 and 3 increase their ‘Receive Error Counter’ (REC) by 1
- CAN node 1 automatically re-transmits the message — and now succeeds
- As a result, node 1 reduces its TEC by 1 and nodes 2 and 3 reduce their REC by 1
The example references a number of concepts that we will detail shortly: Error frames, error
types, counters and states.
The CAN bus error frame
In the illustrative example, the CAN nodes ‘raise Active Error Flags’, thus creating an ‘error frame’ in
response to detecting a CAN error.
To understand how this works, let us first look at a «normal» CAN frame (without errors):
CAN bus bit stuffing
Notice that we highlighted ‘bit stuffing’ across the CAN frame.
Bit stuffing is a subtle, but vital part of the CAN standard. Basically it states that whenever a CAN node
sends five bits of the same logic level (dominant or recessive), it must send one bit of the opposite level.
This extra bit is automatically removed by the receiving CAN nodes. This process helps ensure continuous
synchronisation of the network.
As per the previous example, when CAN node 1 detects an error during the transmission of a CAN message, it
immediately transmits a sequence of 6 bits of the same logic level — also referred to as raising an Active
Error Flag.
If we measure the transmission of a CAN frame via an oscilloscope and digitize the result, we can also
see the stuff bits in practice (see the red timestamp marks):
Active Error Flags
As we just learned, such a sequence is a violation of the bit stuffing rule — aka a ‘Bit Stuffing Error’.
Further, this error is visible to all CAN nodes on the network (in contrast to the ‘Bit Error’ that resulted
in this error flag being raised). Thus, the raising of error flags can be seen as a way of
«globalizing» the discovery of an error, ensuring that every CAN node is informed.
Note that the other CAN nodes will see the Active Error Flag as a Bit Stuffing Error. In
response they also raise an Active Error Flag.
As we’ll explain shortly, it is important to distinguish between the error flags. In particular, the first
error flag
(from the ‘discovering’ node) is often referred to as a ‘primary’ Active Error Flag, while
the error flags of
subsequent ‘reacting’ nodes are referred to as the ‘secondary’ Active Error Flag(s).
3 CAN error frame examples
Let’s look at three example scenarios:
Example 1: 6 bits of error flags
Here, all CAN nodes simultaneously discover that an error exists in a CAN message and raise their error
flags at the same time.
The result is that the error flags all overlap and the total sequence of dominant
bits lasts for 6 bits in total. All CAN nodes will in this case consider themselves the ‘discovering’ CAN
nodes.
This type of simultaneous discovery is less common in practice. However, it could e.g. happen as a
result of Form
Errors (such as a CRC delimiter being dominant instead of recessive), or if a CAN transmitter
experiences a bit error during the writing of a CRC field.
Example 2: 12 bits of error flags
Here, CAN node 1 transmits a dominant bit, but reads it as recessive — meaning that it discovers a Bit Error.
It immediately transmits a sequence of 6 dominant bits.
The other nodes only discover the Bit Stuffing Error
after the full 6 bits have been read, after which they simultaneously raise their error flags, resulting in
a subsequent sequence of 6 dominant bits — i.e. 12 in total.
Example 3: 9 bits of error flags
Here, CAN node 1 has already transmitted a sequence of 3 dominant bits when it discovers a Bit Error and
begins sending 6 dominant bits.
Once halfway through the primary Active Error Flag, nodes 2 and 3 recognize
the Bit Stuffing Error (due to the 3 initial dominant bits being followed by another 3 dominant bits) and
they begin raising their error flags. The result is that the sequence of dominant bits from error flags
becomes 9 bit long.
The above logic of raising error flags is reflected in what we call an ‘active’ CAN error frame.
Note in particular how the secondary error flags raised by various nodes overlap each other — and how the
primary and secondary flags may overlap as well. The result is that the dominant bit sequence from raised
error
flags may be 6 to 12 bits long.
This sequence is always terminated by a sequence of 8 recessive bits, marking the end of the error frame.
In practice, the active error frame may «begin» at different places in the erroneous CAN frame, depending on
when the
error is discovered. The result, however, will be the same: All nodes discard the erroneous CAN frame and
the
transmitting node can attempt to re-transmit the failed message.
Passive Error Flags
If a CAN node has moved from its default ‘active’ state to a ‘passive’ state (more on this shortly), it will only be
able to raise so-called ‘Passive Error Flags’. A Passive Error Flag is a sequence of 6 recessive bits as seen below.
In this case it’s relevant to distinguish between a Passive Error Flag raised by a transmitting node and a receiving
node.
Example 4: Transmitter is Error Passive
As shown in the illustration (Example 4), if a transmitter (such as CAN node 1 in our example) raises a
Passive Error Flag (e.g. in response to a Bit Error), this will correspond to a consecutive sequence of 6
recessive bits.
This is in turn detected as a Bit Stuffing Error by all CAN nodes. Assuming the other CAN
nodes are still in their Error Active state, they will raise Active Error Flags of 6 dominant bits. In other
words, a passive transmitter can still «communicate» that a CAN frame is erroneous.
Example 5: Receiver is Error Passive
In contrast, if a receiver raises a Passive Error Flag this is in practice «invisible» to all other CAN nodes
on the bus (as any dominant bits win over the sequence of recessive bits) — see also Example 5.
Effectively,
this means that an Error Passive receiver no longer has the ability to destroy frames transmitted by
other CAN nodes.
CAN error types
Next, let us look at what errors may cause CAN nodes to raise error flags.
The CAN bus protocol specifies 5 CAN error types:
- Bit Error [Transmitter]
- Bit Stuffing Error [Receiver]
- Form Error [Receiver]
- ACK Error (Acknowledgement) [Transmitter]
- CRC Error (Cyclic Redundancy Check) [Receiver]
We’ve already looked at Bit Errors and Bit Stuffing Errors briefly, both of which are evaluated at the bit
level. The remaining three CAN error types are evaluated at the message level.
Below we detail each error type:
#1 Bit Error
Every CAN node on the CAN bus will monitor the signal level at any given time — which means that a
transmitting CAN node also «reads back» every bit it transmits. If the transmitter reads a different data
bit level vs. what it transmitted, the transmitter detects this as a Bit Error.
If a bit mismatch occurs during the arbitration process (i.e. when sending the CAN ID), it is not
interpreted as a Bit Error. Similarly, a mismatch in the acknowledgement slot (ACK field) does not cause
a Bit Error as the ACK field specifically requires a recessive bit from the transmitter to be
overwritten by a dominant bit from a receiver.
#2 Bit Stuffing Error
As explained, bit stuffing is part of the CAN standard. It dictates that after every 5 consecutive bits of
the same logical level, the 6th bit must be a complement. This is required to ensure the on-going
synchronization of the network by providing rising edges. Further, it ensures that a stream of bits are not
mis-interpreted as an error frame or as the interframe space (7 bit recessive sequence) that marks the end
of a message. All CAN nodes automatically remove the extra bits.
If a sequence of 6 bits of the same logical level is observed on the bus within a CAN message (between the
SOF and CRC field), the receiver detects this as a Bit Stuffing Error aka Stuff Error.
#3 Form Error
This message-level check utilises the fact that certain fields/bits in the CAN message must always be of a
certain logical level. Specifically the 1-bit SOF must be dominant, while the entire 8-bit EOF field must be
recessive. Further, the ACK and CRC delimiters must be recessive. If a receiver finds that any of these are
bits are of an invalid logical level, the receiver detects this as a Form Error.
#4 ACK Error (Acknowledgement)
When a transmitter sends a CAN message, it will contain the ACK field (Acknowledgement), in which the
transmitter will transmit a recessive bit. All listening CAN nodes are expected to send a dominant bit in
this field to verify the reception of the message (regardless of whether the nodes are interested in the
message or not). If the transmitter does not read a dominant bit in the ACK slot, the
transmitter detects this as an ACK Error.
#5 CRC Error (Cyclic Redundancy Check)
Every CAN message contains a Cyclic Redundancy Checksum field of 15 bits. Here, the transmitter has
calculated the CRC value and added it to the message. Every receiving node will also calculate the CRC on
their own. If the receiver’s CRC calculation does not match the transmitter’s CRC, the
receiver detects this as a CRC Error.
CAN node states & error counters
As evident, CAN error handling helps destroy erroneous messages — and enables CAN nodes to retry the
transmission of
erroneous messages.
This ensures that short-lived local disturbances (e.g. from noise) will not
result in
invalid/lost data. Instead, the transmitter attempts to re-send the message. If it wins arbitration
(and there
are no errors), the message is successfully sent.
However, what if errors are due to a systematic malfunction in a transmitting node? This could
trigger an endless loop of sending/destroying the same message — jamming the CAN bus.
This is where CAN node states and error counters come in.
In short, the purpose of CAN error tracking is to confine errors by gracefully reducing the privileges of
problematic CAN nodes.
Specifically, let’s look at the three possible states:
-
Error Active: This is the default state of every CAN node, in which
it is able to
transmit data
and raise ‘Active Error Flags’ when detecting errors -
Error Passive: In this state, the CAN node is still able to
transmit data, but it now
raises
‘Passive Error Flags’ when detecting errors. Further, the CAN node now has to wait for an extra 8 bits
(aka
Suspend Transmission Time) in addition to the 3 bit intermission time before it can resume data
transmission (to
allow other CAN nodes to take control of the bus) -
Bus Off: In this state, the CAN node disconnects itself from the
CAN bus and can no
longer
transmit data or raise error flags
Every CAN controller keeps track of its own state and acts accordingly.
CAN nodes shift state depending on the value of their error counters. Specifically, every CAN node
keeps track on a Transmit Error Counter (TEC) and Receive Error Counter
(REC):
- A CAN node
enters the Error Passive state if the REC or TEC exceed 127 - A CAN node
enters the Bus Off state if the TEC exceeds 255
How do the error counters change?
Before we get into the logic of how error counters are increased/reduced, let us revisit the CAN error frame
as well
as the primary/secondary error flags.
As evident from the CAN error frame illustration, a CAN node that observes a dominant bit after its
own
sequence of 6
dominant bits will know that it raised a primary error flag. In this case, we can call this CAN
node the
‘discoverer’ of the error.
At first, it might sound positive to have a CAN node that repeatedly discovers errors and reacts promptly by
raising
an error flag before other nodes. However, in practice, the discoverer is typically also the culprit causing
errors
— and hence it is punished more severely as per the overview.
There are some additions/exceptions to the above rules, see e.g. this overview.
Most are pretty straight-forward based on our previous illustrative example. For example, it seems clear that CAN
node 1 would increase the TEC by 8 as it discovers the Bit Error and raises an error flag. The other nodes in
this
case increase their REC by 1.
This has the intuitive consequence that the transmitting node will quickly reach the Error Passive and eventually
Bus
Off states if it continuously produces faulty CAN messages — whereas the receiving nodes do not change state.
The case where a receiver raises the primary error flag may seem counter-intuitive. However, this could for
example
be the case if a receiver CAN node is malfunctioning in a way that causes it to incorrectly detect errors in
valid
CAN messages. In such a case, the receiver would raise the primary error flag, effectively causing an error.
Alternatively, it can happen in cases where all CAN nodes simultaneously raise error flags.
CAN/LIN data & error logger
The CANedge1 lets you easily
record data from 2 x CAN/LIN buses to an 8-32 GB SD card — incl. support for logging CAN/LIN errors. Simply
connect it to e.g. a car or truck to start logging —
and decode the data via free
software/APIs.
Further, the CANedge2
(WiFi) and CANedge3 (3G/4G)
let you push data to your own server — and update devices over-the-air.
learn
about the CANedge
Examples: Generating & logging error frames
We have now covered the theoretical basics of CAN errors and CAN error handling. Next, let us look at generating and
logging errors in practice. For this we will use a couple of CANedge devices — and for some tests a
PCAN-USB device.
Tip: Download the MF4 data for the tests to view the data in asammdf or CANalyzer.
download data
Test #1: No CAN bus errors
As a benchmark, we start with a test involving no CAN bus errors. Here, a CANedge2 ‘transmitter’ sends
data to another CANedge2 ‘receiver’ — and both log CAN bus errors.
By loading the MF4 log
file in the asammdf GUI we
verify that no CAN errors occurred during this test, which is to be expected.
Test #2: Removing the CAN bus terminal resistor
In this test, we remove the CAN termination in the middle of a log session. This effectively corresponds to
immediately setting the bit level to dominant. As a result, the CANedge2 transmitter immediately starts
logging Bit Errors (which occur when it attempts to transmit a recessive bit, but reads a
dominant bit). The
CANedge2 Receiver logs Bit Stuffing Errors as it detects 6 consecutive dominant bits.
These errors are
recorded until the termination is added again.
Lack of termination is rarely a practical issue if you’re recording data from a vehicle, machine etc.
However, it’s a common issue when working with ‘test bench’ setups. Here, the lack of termination may
cause confusion as it can be difficult to distinguish from an inactive CAN bus. If in doubt, enabling
error frame logging on the CANedge can be useful in troubleshooting.
Transmitter Bit Errors
Receiver Bit Stuffing Errors
Test #3: Setting an incorrect baud rate
In this test we configure the CANedge receiver node to have a baud rate of 493.827K vs. the baud rate of the
transmitter of 500K. This is a fairly extreme difference and results in ACK Errors for the
transmitter and Bit
Stuffing Errors for the receiver.
In more realistic scenarios, smaller differences in the baud
rate
configuration of
various nodes may cause intermittent error frames and thus message loss.
This example is rather extreme. However, in practice we have sometimes seen CAN buses that use standard
bit rates
(250K, 500K, …), but with specific bit timing settings that differ from the ones that are typically
recommended
(and hence used by the CANedge). This will not lead to a complete shut-down of the communication, but
rather
periodic frame loss of a few percentages. To resolve this, you can construct an ‘advanced bit rate’ in
the
CANedge configuration, essentially setting up the bit-timing to better match the CAN bus you’re logging
from.
Transmitter ACK Error
Receiver Bit Stuffing Errors
Test #4: Removing the acknowledging CAN node
In this test, we use three CANedge units configured as follows:
-
CANedge1: Configured to
acknowledge data -
CANedge2 A:
Configured in ‘silent mode’ (no acknowledgement) -
CANedge2 B:
Configured to transmit a CAN frame every 500 ms
In the default setup, data is transmitted by the CANedge2 B onto the CAN bus and recorded with no errors.
However, if we remove the CANedge1 from the bus there are no longer any CAN nodes to acknowledge the frames
sent by the transmitter.
As a result, the transmitter detects ACK Errors. In response, it increases its
Transmit Error Counter and raises Active Error Flags onto the CAN bus. These are in turn
recorded by CANedge2 A (which silently monitors the bus) as Form Errors.
This is due to the fact that the transmitter raises them upon identifying the lack of a dominant
bit in the ACK slot. As soon as a dominant bit is observed by the receiver in the subsequent EOF field
(which should be recessive), a Form Error is detected.
As evident, the transmitter broadcasts 16 Active Error Flags as its TEC is increased from 0 to 16 x 8 =
128.
The transmitter has now exceeded the threshold of a TEC of 127 and enters Error Passive mode. As a
result,
the transmitter still experiences ACK Errors, but now only raises Passive Error Flags (not visible to
the
receiver). At this point, the transmitter keeps attempting to transmit the same frame — and the receiver
keeps recording this retransmission sequence.
This type of error is one we often encounter in our support tickets. Specifically, users may be trying to
use our CAN loggers to record data from a single CAN node (such as a sensor-to-CAN module like our
CANmod). If they decide to enable ‘silent mode’ on the CANedge in such an installation, no CAN nodes
will acknowledge the single CAN node broadcasting data — and the result will either be empty log files,
or log files filled with retransmissions of the same CAN frame (typically at very high frequency).
Transmitter ACK Errors
Receiver Form Errors
Test #5: CAN frame collisions (no retransmission)
When setting up a CAN bus, it is key to avoid overlapping CAN IDs. Failing to do so can result in frame
collisions
as two CAN nodes may both believe they’ve won the arbitration — and hence start transmitting their frames at
the same time.
To simulate this, we use the same setup as in test #4. In addition, we connect a PCAN-USB device as a
secondary
transmitter.
The CANedge2 transmitter is now configured to output a single CAN frame every 10 ms with CAN ID 1 and a
payload of
eight 0xFF bytes. Further, we configure the CANedge2 to disable retransmission of frames that were disrupted
by
errors. The PCAN-USB outputs an identical CAN frame every 2 ms with the 1st byte of the payload changed to
0xFE. The
PCAN device has retransmissions enabled.
This setup quickly creates a frame collision, resulting in the CANedge and PCAN transmitters detecting a
Bit
Error.
In response to this, both raise an Active Error Flag, which is detected as a Bit Stuffing
Error by the
CANedge
receiver. The PCAN device immediately attempts a retransmission and succeeds, while the CANedge waits with
further
transmission until the next message is to be sent.
This type of error should of course never happen in e.g. a car, since the design and test processes will
ensure
that all CAN nodes communicate via globally unique CAN identifiers. However, this problem can easily
occur if
you install a 3rd party device (e.g. a sensor-to-CAN module) to inject data into an existing CAN bus. If
you do
not ensure the global uniqueness of the CAN IDs of external CAN nodes, you may cause frame collisions
and hence
errors on the CAN bus. This is particularly important if your external CAN node broadcasts data with
high
priority CAN IDs as you may then affect safety critical CAN nodes.
USB-to-CAN transmitter Bit Error
CANedge transmitter Bit Error
CANedge receiver Bit Stuffing Error
Test #6: CAN frame collisions (incl. retransmission)
In this test, we use the same setup as before, but we now enable retransmissions on the CANedge2 transmitter.
In this case, the frame collision results in a sequence of subsequent frame collisions as both the CANedge2
and the PCAN-USB device attempt to re-transmit their disrupted messages.
Due to the resulting Bit Errors, both raise a total of 16 Active Error Flags, which are detected as
Bit Stuffing Errors
by the silent CANedge2 receiver. Both transmitters then enter Error Passive mode and stop raising Active Error
Flags, meaning none of them can destroy CAN frames on the bus. As a result, one of the transmitters will
succeed in transmitting a full message, thus ending the retransmission frenzy — and enabling both devices to
resume transmission. However, this only lasts for a few seconds before another collision occurs.
The collision handling is a good example of how effective the CAN error handling is at ‘shutting down’
potentially
problematic sequences and enabling CAN nodes to resume communication. If a frame collision occurs, it is likely
that both CAN nodes will be set up to attempt retransmission, which would cause a jam if not for the error
handling and confinement.
USB-to-CAN transmitter Bit Errors x 16
CANedge transmitter Bit Errors x 16
CANedge receiver Bit Stuffing Errors x 16
Similar to CAN bus errors, the LIN protocol also specifies a set of four error types, which we outline briefly below.
The CANedge supports both CAN/LIN error frame logging.
As for the CAN CRC Error, this error type implies that a LIN node has calculated a different checksum vs. the one
embedded in the LIN bus frame by the transmitter. If you’re using the CANedge as a LIN Subscriber, this error
may indicate that you’ve configured the device ‘frame table’ with incorrect identifiers for some of the LIN
frames on the bus.
This can in turn be used to ‘reverse engineer’ the correct lengths and IDs of proprietary LIN frames via a
step-by-step procedure. See the CANedge Docs for details.
These occur if a specific part of the LIN message does not match the expected value, or if there is a mismatch
between what is transmitted vs. read on the LIN bus.
This error indicates an invalid synchronization field in the start of the LIN frame. It can also indicate a large
deviation between the configured bit rate for a LIN node vs. the bit rate detected from the synchronization
field.
Transmission errors can occur for LIN identifiers registered as SUBSCRIBER messages. If there are no nodes
responding to a SUBSCRIBER message, a transmission error is logged.
Example use cases for CAN error frame logging
CAN bus diagnostics in OEM prototype vehicles
An automotive OEM may have the need to record CAN error frames in the field during late stage prototype
testing. By deploying a CANedge, the OEM engineering team will both be able to troubleshoot issues based on
the actual CAN signals (speed, RPM, temperatures) — as well as issues related with the lower layer CAN
communication in their prototype systems. This is particularly vital if the issues of interest are
intermittent and e.g. only happen once or twice per month. In such scenarios, CAN bus interfaces are not
well suited — and it becomes increasingly relevant to have a cost-effective device to enable scalable
deployments for faster troubleshooting.
Remotely troubleshooting CAN errors in machinery
An OEM or aftermarket user may need to capture rare CAN error events in their machines. To do so, they deploy
a CANedge2 to record the CAN data and related error frames — and automatically upload the data via WiFi to
their own cloud server. Here, errors are automatically identified and an alert is sent to the engineering
team to immediately allow for diagnosing and resolving the issue. For 3G/4G transfer, a CANedge3 can alternatively be used.
FAQ
No, error frame logging is a highly specific functionality — and only relevant if you know that you need to
record this information. Typically, it’s mainly of value during diagnostics by OEM engineers — and less so for
aftermarket users. In addition, if systematic errors occur they can quickly bloat the log file size.
With the CANedge2 you can of course enable/disable error frame logging over-the-air.
Yes, the CANedge is able to record all CAN/LIN error types. It does, however, not currently record its own error
counter status as this is deemed less relevant from a logging perspective.
The CANedge is only able to raise error flags onto the CAN bus if it is configured in its ‘normal’ mode, in which
it is also able to transmit messages. If in ‘restricted’ mode it can listen to CAN frames and acknowledge CAN
frames — but not raise Active Error Flags onto the bus. In ‘monitoring’ mode (aka ‘silent mode’) it can listen
to the CAN bus traffic, but not acknowledge messages nor raise Active Error Flags.
The CANedge will always record internal CAN/LIN error frames.
If a CAN frame is erroneous, resulting in an error frame, the CANedge generally only records the error type —
without any data related to the erroneous frame (beyond the timestamp). One exception to this rule is for
acknowledgement errors, where the CANedge will still record unacknowledged CAN frames (incl. from retransmission
attempts).
Some researchers have pointed out the risk that ‘bad actors’ could utilize the CAN bus error handling
functionality to enforce remote ‘bus off’ events for safety-critical ECUs. This is a good example of why CAN bus
data loggers & interfaces like the CANedge2 with remote
over-the-air data transfer and updates need to be highly secure (see also our intro to CAN
cybersecurity). For a nice overview of a remote bus off attack, see this
intro by Adrian Colyer.
For more intros, see our guides section — or download the
‘Ultimate Guide’ PDF.
Need to log CAN bus data & errors?
Get your CAN logger today!
Recommended for you
What are Error Active, Error Passive, and Bus off of CAN Bus?
Just to give a little background to the answer:
In order to prevent malfunctioning nodes from disturbing, or even blocking, an entire system, the CAN protocol implements a sophisticated fault confinement mechanism. The CAN protocol is intended to be orthogonal, i.e. all nodes address faults in the same manner. Fault confinement is provided where each node constantly monitors its performance with regard to successful and unsuccessful message transactions. A Transmit Error Counter (TEC) and a Receive Error Counter (REC) create a metric for communication quality based on historic performance. Each node will act on its own bus status based on its individual history. As a result, a graceful degradation allows a node to disconnect itself from the bus i.e. stop transmitting. This means that a permanently faulty device will cease to be active on the bus (go into Bus Off state), but communications between other nodes can
continue unhindered. If the bus media is severed, shorted or suffers from some other failure mode the ability to continue communications is dependent upon the condition and the physical interface used.
Fault confinement is a checking mechanism that makes it possible to distinguish between short disturbances (e.g. switching noise from a nearby power cable couples into the transmission media) and permanent failures (e.g. a node is malfunctioning and disturbs the bus).
Manipulation of the error counters is asymmetric. On a successful transmission, or reception, of a message, the respective error counter is decremented if it had not been at zero. In the case of a transmit or receive error the counters are incremented, but by a value greater than the value they would be decrement by following a successful message transaction.
If a node detects a local error condition (e.g. due to local conducted noise, application software, etc.), its resulting error flag (primary error flag) will subsequently cause all other nodes to respond with an error flag too (secondary error flags). It is important that a distinction is made between the nodes that detected an error first and the nodes which responded to the primary error flag. If a node transmits an active error frame, and it monitors a dominant bit after the sixth bit of its error flag, it considers itself as the node that has detected the error first. In the case where a node detects errors first too
often, it is regarded as malfunctioning, and its impact to the network has to be limited. Therefore, a node can be in one of three possible error states:
Error active
Both of its error counters are less than 128. It takes part fully in bus communication and signals an error by transmission of an active error frame.This consists of sequence of 6 dominant bits followed by 8 recessive bits, all other nodes respond with the appropriate error flag, in response to the violation of the bit stuffing rule.
Error passive
A node goes into error passive state if at least one of its error counters is greater than 127. It still takes part in bus activities, but it sends a passive error frame only, on errors. Furthermore, an error passive node has to wait an additional time (Suspend Transmission Field, 8 recessive bits after Intermission Field) after transmission of a message, before it can initiate a new data transfer. The primary passive error flag consists of 6 passive bits and thus is “transparent” on the bus and will not “jam” communications.
Bus Off
If the Transmit Error Counter of a CAN controller exceeds 255, it goes into the bus off state. It is disconnected from the bus (using internal logic) and does not take part in bus activities anymore. In order to reconnect the protocol controller, a so-called Bus Off recovery sequence has to be executed. This usually involves the re-initialization and configuration of the CAN controller by the host system, after which it will wait for 128 * 11 recessive bit times before it commences communication.
-
When a receiver detects an error, the REC will be increased by 1, except when the detected error was a Bit Error during the sending of an Active error Flag or an Overload Flag.
-
When a receiver detects a dominant bit as the first bit after sending an Error Flag, the REC will be increased by 8.
-
When a transmitter sends an Error Flag, the TEC is increased by 8. Exception 1: If the transmitter is Error Passive and detects an ACK Error because of not detecting a dominant ACK and does not detect a dominant bit while sending its Passive Error Flag. Exception 2: If the transmitter sends an Error Flag because a Stuff Error occurred during arbitration, and should have been recessive, and has been sent as recessive but monitored as dominant.
-
If the transmitter detects a Bit Error while sending an Active Error Flag or an Overload Frame, the TEC is increased by 8.
-
If a receiver detects a Bit Error while sending an Active Error Flag or an Overload Flag, the REC is increased by 8.
-
Any node tolerates up to 7 consecutive dominant bits after sending an Active Error Flag, Passive Error Flag or Overload Flag. After detecting the fourteenth consecutive dominant bit (in case of an Active Error Flag or an Overload Flag) or after detecting the eighth consecutive dominant bit following a Passive Error Flag, and after each sequence of additional eight consecutive dominant bits, ever y transmitter increases its TEC by 8 and every receiver increases its REC by 8.
-
After successful transmission of a frame (getting ACK and no error until EOF is finished), the TEC is decreased by 1 unless it was already 0.
-
After the successful reception of a frame (reception without error up to the ACK Slot and the successful sending of the ACK bit), the REC is decreased by 1, if it was between 1 and 127. If the REC was 0, it stays 0, and if it was greater than 127, then it will be set to a value between 119 and 127.
-
A node is Error Passive when the TEC equals or exceeds 128, or when the REC equals or exceeds 128. An error condition letting a node become Error Passive causes the node to send an Active Error Flag.
-
A node is Bus Off when the TEC is greater than or equal to 256.
-
An Error Passive node becomes Error Active again when both the TEC and the REC are less than or equal to 127.
-
A node which is Bus Off is permitted to become Error Active (no longer Bus Off) with its error counters both set to 0 after 128 occurrence of 11 consecutive recessive bits have been monitored on the bus.
The CAN protocol is the most important very less or ignorable errorless protocol. CAN protocol is also having multiple methods to prevent the error Like other protocols. You would have learned different methods for error in your engineering education time period. Basically, these methods are used in every protocol. But we are sometimes thinking it is difficult, because of ignorance in our engineering. If you will really trying to communicate in between the two or more processors or machines using any protocol, obviously you will face a lot of problems and you need to fix it to reduce the error in data communication.
CAN protocol is having multiple methods that can detect the different errors in CAN protocol. The CAN-FD is also having the same types of error. There are 5 types of error in CAN protocol. In each CAN controller, it will have an error detection module that can detect the errors as:
- Bit Error
- ACK Error
- Stuff Error
- CRC Error
- Form Error
Among the above 5 types of error, if any error detects by the CAN controller, it notifies the bus by sending a flag called CAN error frame.
CAN Protocol Bit-Error
Whenever a node sending by the transmitter unit with any bit on the CAN bus, it also monitors or receives the same data bit by its receiver driver. The ECU or node must detect the bit error if there is a difference between the transmitted bit and received bit in the CAN frame. That means if the Tx Bit is not equal to Rx bit then it will flag an error and send an error frame on the CAN bus.
An exception in CAN protocol is the sending of a recessive bit during the stuffed bit-stream of the Arbitration field or during any ACK Slot; in this case, no Bit error occurs when a dominant bit is monitored. If a transmitter sending a PASSIVE Error Flag and detecting a dominant bit, it does not interpret this as a Bit error. The bit error is one of the high priority CAN protocol error types. If the bit error;
- Detects in the CAN identifier field, it doesn’t send any error frame, instead, it stops sending a data frame for arbitration purposes.
- Detects in ACK bit, it considers as an acknowledgement signal for that transmitter.
- Does not detect an ACK bit, then the transmitter node detects it as ACK error instead of bit error.
CAN Protocol ACK Error
The CAN data frame is having consists of the ACK field with 2-bits. The first bit is the ACK bit and the second one is the ACK delimiter bit. Basically, after the completion of the data field, the Transmitter ECU makes the bus recessive. But the receiver driver of the Transmitter ECU will be monitoring this bit for detecting the ACK signal. Basically, bit monitoring happened for bit error, but here it is a special case where if the bit error occurs then the transmitter ECU will understand that the receiver ECU received the data successfully. if no bit error then there is an ACK error because of no data received by any ECU or node. The ACK error is one of the high priority CAN protocol error types.
CAN Protocol Stuff Error
The bit stuffing is a method of error detection in CAN protocol. This stuff check serves to check the bitstream on the CAN bus. Basically, this standard specifies the CAN protocol specification. When five consecutive bits of the same level have been transmitted by a node, it will add a sixth bit of the complementary level to the outgoing bitstream. The receiver should also remove this 6th complimentary from the real data. This method is basically called an NRZ-5 method. This is basically used to avoid the excessive DC components on the CAN bus, but it also gives the receivers an extra opportunity to detect the errors; if it detects more than 5 consecutive homogenious recessive or dominant bits.
This is used in the CAN network for synchronization purposes. To know more about it you can ask your query in our PiEST Forum. if more than five homogeneous contiguous bits are received by the receiver, then the receiver ECU will detect the bit stuff error. The STUFF error is one of the high priority CAN protocol error types.
CAN Protocol CRC Error
The CAN data or remote frame having consists of a 15-bit CRC calculated by the transmitter. When the receiver receives this frame, it will also receives that CRC data field sent by the transmitter ECU. At the same time, the receiver will also calculate a CRC by using the same logic as the transmitter has done it. So after the receiver calculates CRC, the receiver CAN controller will compare both the CRC. If it is same then there is no CRC error, otherwise it informs a CRC error to the CAN controller. Then the CAN controller flags a CRC error by sending an error frame on the CAN bus.
Basically, the CRC gets calculated by the polynomial calculation. The polynomial R(x) associated with the arriving data or remote frame should equal a multiple of the generator polynomial G(x) specified by ISO 11898-1 standard. If there is no CRC error, then the data or remote frame was corrupted during its transmission. The CRC error is one of the high priority CAN protocol error types.
CAN Protocol Form Error
This type of error is basically used for the purpose of the frame check. In CAN frame, some parts of its message have a fixed format. That means the CAN standard ISO-11898 defines exactly what levels must occur and when. These are the CRC Delimiter, ACK Delimiter, End of Frame, and also the Intermission fields, but there is some extra special error checking rules for that. The CAN standard defines recessive all these bits, so if any of these bits detects dominant, it flags a form error. The FORM error is one of the high priority CAN protocol error types.
Error Detection
There are five types of CAN error can introduce on CAN-BUS by receiver and transmitter node-
- Bit error
- Stuff error
- CRC error
- Acknowledgment error
- Form Error
Bit Error(Introduce By Transmitter)
As I discussed in Bit Monitoring chapter, Every transmitter node reads back its transmitted bit from CAN line along with other ECUs But if it will not get read bit same as it transmitted then transmitted node stop the further transmission and introduce an error frame on CAN line. This error is known as bit error.
Note:
- If bit mismatch detected during Arbitration field or ACK then transmitter neither looks it as bit error nor introduce any error frame because as per the CAN standard these fields has defined functionality.
- CRC Delimeter, ACK and EOF are also fixed length fields in CAN frame so it will also not be the part of bit error frame execution if more than five consecutive bits found.
Stuff Error(Introduce By Receiver)
As I discussed in Bit Stuffing chapter, More than 5 consecutive bits of the same polarity in CAN frame between the start of Frame(SOF) to CRC field is considered as a faulty frame on CAN Bus and it signaled as stuff error on CAN line.
CRC Error(Introduce By Receiver)
The transmitter transmits CRC of transmitted data at CRC field of CAN frame and receivers also calculate CRC on received data. If the receiver found Calculated CRC is different from received CRC at CRC field then receiver signaled it as CRC error and introduce an error frame on CAN line.
ACK Error(Introduce By Transmitter)
After Transmission of CRC field of CAN frame Transmitter send ACK (a recessive bit) and receiver makes it dominant as a part of acknowledgment to the transmitter. During readback, transmitter found the dominant bit and consider it as receiver acknowledgment and if it reads a recessive bit then transmitter signaled it as ACK error and introduce an error frame.
Form Error(Introduce By Receiver)
As per CAN Frame Format, there are some fields of fixed length and format like CRC Delimeter, ACK Delimeter, EOF ,InterFrame Spaceand if it is detected corrupted at receiver side then it signaled as Form Error and Node will introduce an error frame on CAN line.
Error Confinement Mechanism
In CAN network Every node is very honest. if any node transmits/receive continuous faulty frame then it will disconnect itself from CAN network after a threshold limit if fault not recovered. To decide this threshold every Node has two error counters: Transmit error Counter(TEC) and Receive Error Counter(REC) to keep the track of error generated because of above-discussed situations. On the basis of these counter, Nodes are categories in three error state-
- Active Error state(When TEC<=127 and REC<=127)
- Passive Error state( When TEC>127 or REC>127 )
- Bus-Off State(When TEC>255)
Active Error State
A CAN Node enters into Active Error State when TEC<=127 and REC<=127 In This State Node can participate in all CAN activity like –
A node can Transmit all type of Frames like Data Frame, Remote Frame, Overload Frame, and active Error Frame(6-12 Dominant bit)
Passive Error State
A CAN Node enters into Passive Error State when TEC<=127 or REC<=127. This state still has a chance to come back in error-free state.In This State a Node still can participate in all CAN activity like –
- A node can Transmit all type of Frames like Data Frame, Remote Frame, Overload Frame, but Passive Error Frame(6-12 Recessive bit)
- A node can come back to in error active state if it starts transmission of the correct frames and its counter value comes under 127.
Bus-Off State
A CAN Node enters into Bus-Off State When TEC>255 . In this state CAN node will be removed from CAN network and now it will no longer available on CAN network to participate in any CAN activity.
Промышленная сеть реального времени CAN представляет собой сеть с общей средой передачи данных. Это означает, что все узлы сети одновременно принимают сигналы передаваемые по шине. Невозможно послать сообщение какому-либо конкретному узлу. Все узлы сети принимают весь трафик передаваемый по шине. Однако, CAN-контроллеры предоставляют аппаратную возможность фильтрации CAN-сообщений.
Каждый узел состоит из двух составляющих. Это собственно CAN контроллер, который обеспечивает взаимодействие с сетью и реализует протокол, и микропроцессор (CPU).
Рис. 1. Топология сети CAN.
CAN контроллеры соединяются с помощью дифференциальной шины, которая имеет две линии — CAN_H (can-high) и CAN_L (can-low), по которым передаются сигналы. Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Логическая единица — в случае когда сигналы CAN_H и CAN_L одинаковы (отличаются менее чем на 0.5 В). Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях. Логический ноль — называется доминантным битом, а логическая единица — рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN. При одновременной передаче в шину лог. нуля и единицы, на шине будет зарегестрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).
Типы сообщений сети CAN.
Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:
- Data Frame
- Remote Frame
- Error Frame
- Overload Frame
Data Frame — это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:
- поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:
- для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
- для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)
Следует отметить, что поле идентификатора, несмотря на свое название никак не идентифицирует само по себе ни узел в сети, ни содержимое поля данных. Для Data кадра бит RTR всегда выставлен в логический ноль (доминантный сигнал).
- поле данных (data field) содержит от 0 до 8 байт данных
- поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок
- слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.
Рис. 2. Data frame стандарта CAN 2.0A.
Remote Frame — это Data Frame без поля данных и с выставленным битом RTR (1 — рецессивные бит). Основное предназначение Remote кадра — это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).
Error Frame — это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.
Overload Frame — повторяет структуру и логику работы Error кадра, с той разницей, что он используется перегруженным узлом, который в данный момент не может обработать поступающее сообщение, и поэтому просит при помощи Overload-кадра о повторной передаче данных. В настоящее время Overload-кадр практически не используется.
Контроль доступа к среде передачи (побитовый арбитраж).
Поле арбитража CAN-кадра используется в CAN для разрешения коллизий доступа к шине методом не деструктивного арбитража. Суть метода не деструктивного арбитража заключается в следующем. В случае, когда несколько контроллеров начинают одновременную передачу CAN кадра в сеть, каждый из них сравнивает, бит, который собирается передать на шину с битом, который пытается передать на шину конкурирующий контроллер. Если значения этих битов равны, оба контроллера передают следующий бит. И так происходит до тех пор, пока значения передаваемых битов не окажутся различными. Теперь контроллер, который передавал логический ноль (более приоритетный сигнал) будет продолжать передачу, а другой (другие) контроллер прервёт свою передачу до того времени, пока шина вновь не освободится. Конечно, если шина в данный момент занята, то контроллер не начнет передачу до момента её освобождения.
Рис. 3. Побитовый арбитраж на шине CAN.
Методы обнаружения ошибок.
CAN протокол определяет пять способов обнаружения ошибок в сети:
- Bit monitoring
- Bit stuffing
- Frame check
- ACKnowledgement Check
- CRC Check
Bit monitoring — каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.
Bit stuffing — когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.
Frame Check — некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.
ACKnowledgement Check — каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.
CRC Check — каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.
Механизм ограничения ошибок (Error confinement).
Каждый узел сети CAN, во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). Все остальные узлы обнаруживают Error Frame и принимают соответствующие действия (сбрасывают принятое сообщение). Кроме того, каждый узел ведет два счетчика ошибок: Transmit Error Counter (счетчик ошибок передачи) и Receive Error Counter (счетчик ошибок приема). Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.
Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.
Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют. Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла. Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).
Адресация и протоколы высокого уровня
В CAN не существует явной адресации сообщений и узлов. Протокол CAN нигде не указывает что поле арбитража (Identification field + RTR) должно использоваться как идентификатор сообщения или узла. Таким образом, идентификаторы сообщений и адреса узлов могут находится в любом поле сообщения (в поле арбитража или в поле данных, или присутствовать и там, и там). Точно также протокол не запрещает использовать поле арбитража для передачи данных.
Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP — Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.
Рис. 4. Логическая структура протокола CAN.
Существует множество таких высокоуровневых протоколов. Наиболее распространенные из них это:
- DeviceNet
- CAL/CANopen
- SDS
- CanKingdom
Физичекий уровень протокола CAN
Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411).
В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898. ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом. Физический уровень CAN реализован в специальных чипах — CAN приемо-передатчиках (transceivers), которые преобразуют обычные TTL уровни сигналов используемых CAN-контроллерами в уровни сигналов на шине CAN. Наиболее распространенный CAN приемо-передатчик — Phillips 82C250, который полностью соответствует стандарту ISO 11898.
Махимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/sec. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью света и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети. Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:
| скорость передачи | максимальная длина сети |
| 1000 Кбит/сек | 40 метров |
| 500 Кбит/сек | 100 метров |
| 250 Кбит/сек | 200 метров |
| 125 Кбит/сек | 500 метров |
| 10 Кбит/сек | 6 километров |
Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.