Can ошибка ewl

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.

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.

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.

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).

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.

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.

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.

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.

The CAN bus protocol specifies 5 CAN error types:

1. Bit Error [Transmitter]
2. Bit Stuffing Error [Receiver]
3. Form Error [Receiver]
4. ACK Error (Acknowledgement) [Transmitter]
5. 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.

#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:

1. 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
2. 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)
3. Bus Off: In this state, the CAN node disconnects itself from the
   CAN bus and can no
   longer
   transmit data or raise error flags

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.

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

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.

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.

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.

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.

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.