CAN Bus Error Management

Hello! Welcome to the sixth and final lesson in our module on CAN bus fundamentals.

In our previous lessons, we've focused on how successful communication happens on the CAN bus, from the frame structure and arbitration to the different identifier formats. You now have a solid understanding of how a well-behaved network operates.

However, the true strength of CAN, especially in safety-critical automotive systems, lies in its remarkable robustness. This robustness comes from a sophisticated, built-in system for handling faults. Today, we will explore exactly what happens when things go wrong. This lesson will classify CAN bus error types and describe the powerful error detection and management mechanisms that are part of the protocol.

For your role as both a system tester and a developer, this knowledge is not just theoretical; it's a fundamental diagnostic skill. When you encounter a silent ECU or a flood of strange messages on the bus, understanding the principles we'll cover today is your first step to identifying the root cause.

The Five Layers of Error Detection

The CAN protocol doesn't rely on a single method to catch errors; it employs five distinct mechanisms, creating a highly reliable system. Two of these operate at the bit level, and three operate at the message level.

To get a comprehensive overview of these five mechanisms, please start by reading the following section from an article by Kvaser, a respected manufacturer of CAN tools.

As you've just read, the protocol is constantly cross-checking itself. Let's summarize and categorize these checks based on which node is responsible for the detection:

• Detected by the Transmitter:

  1. Bit Error: A transmitter always listens to the bus as it sends a message. If it sends a bit but reads back a different value, it flags a Bit Error. The key exceptions, as we've learned, are during the arbitration field (where losing arbitration is expected) and the ACK slot (where a recessive bit is expected to be overwritten by a dominant one).
  2. Acknowledgement (ACK) Error: The transmitter sends a recessive bit in the ACK slot. It expects at least one other node on the bus to pull that bit dominant to acknowledge correct reception. If the slot remains recessive, the transmitter knows no node has received the message correctly.

• Detected by Receivers:
  3. Stuff Error: As we know, after five consecutive identical bits, a "stuff bit" of the opposite polarity must be inserted. If any receiver sees a sixth consecutive identical bit, it immediately knows the bit stuffing rule has been violated and flags a Stuff Error.
  4. Form Error: Certain parts of a CAN frame have a fixed format (e.g., the CRC delimiter and End-of-Frame must be recessive). If a receiver detects a dominant bit in one of these fixed-format recessive fields, it flags a Form Error.
  5. Cyclic Redundancy Check (CRC) Error: The transmitter calculates a 15-bit checksum based on the message content and includes it in the CRC field. Every receiver performs the same calculation on the message it receives. If a receiver's calculated CRC doesn't match the CRC in the frame, it flags a CRC Error.

Sounding the Alarm: The Error Frame

When any node detects one of the errors above, it doesn't stay silent. It immediately broadcasts an Error Frame to inform all other nodes on the network that the last message was corrupt and should be discarded. The Error Frame intentionally violates the bit-stuffing rule to make it unmistakable.

There are two types of Error Frames, which depend on the "health" of the node that sends it.

• Active Error Frame: Consists of 6 consecutive dominant bits. This is transmitted by a "healthy" (Error-Active) node. Because it's a sequence of dominant bits, it overrides any other message on the bus, effectively destroying the corrupt frame and ensuring all nodes see the error.
• Passive Error Frame: Consists of 6 consecutive recessive bits. This is transmitted by a faulty (Error-Passive) node. Because it's recessive, it won't override other bus traffic. The node is essentially "whispering" about the error without having the power to stop the whole conversation.

The video below gives a brief introduction to these concepts.

Fault Confinement: Preventing a "Babbling Idiot"

So, what stops a single, malfunctioning ECU from constantly detecting errors, sending Active Error Frames, and grinding the entire network to a halt? This is where CAN's most elegant feature, fault confinement, comes into play.

Each CAN node maintains two internal counters:

• Transmit Error Counter (TEC)
• Receive Error Counter (REC)

These counters follow a simple set of rules:

• When a transmitter sends an erroneous frame, its TEC increases by 8.
• When a receiver detects an error, its REC increases by 1.
• On a successful transmission or reception, the respective counters are decreased.

This logic correctly assumes that a transmitter is more likely to be the source of an error than a receiver, so it is "punished" more harshly. Based on the values of these counters, a node can be in one of three states:

1. Error Active: The default state (TEC < 128 and REC < 128). The node participates normally in communication and sends Active Error Frames when it detects a fault.
2. Error Passive: Entered if TEC > 127 or REC > 127. The node can still participate in communication but can only send Passive Error Frames. It also has to wait an additional period of time after a message before it can try to transmit, giving other nodes priority.
3. Bus-Off: Entered if TEC > 255. The node is now considered so faulty that it is completely disconnected from the bus by its own controller. It cannot send or receive any messages until it is reset by the application software.

This state machine gracefully isolates a problematic node from the network. The following state diagram provides a perfect visual summary of these transitions.

To see a clear explanation of this state machine, watch this focused video.

From Theory to Practice: Errors in System Testing

As a system tester, you won't just think about these errors abstractly; you'll see them in your logging tools. Knowing how a physical fault translates to a specific CAN error type is a critical debugging skill.

The following are common scenarios you might create or encounter during testing:

• Scenario: Forgetting the 120-ohm termination resistor on a bench setup.

  • Result: The bus voltage levels will be incorrect. A transmitter attempting to send a recessive bit may see a dominant level instead.
  • Logged Errors: The transmitter will log Bit Errors. Receivers will likely log Stuff Errors from the resulting invalid bit sequences.

• Scenario: A logger is connected in "silent mode" to a single broadcasting ECU (so no node is sending acknowledgements).

  • Result: The transmitting ECU never sees its messages acknowledged.
  • Logged Errors: The transmitter will log a stream of ACK Errors and will repeatedly re-transmit the same message until it goes Error-Passive and then Bus-Off. A listening-only logger would see the error frames generated by the transmitter.

• Scenario: Two ECUs are accidentally configured to transmit messages with the exact same CAN ID.

  • Result: They will arbitrate successfully, but once they start sending their data payload, a bit difference will cause a conflict.
  • Logged Errors: Both transmitters will detect a Bit Error at the point of conflict and will send an Active Error Frame.

The CSS Electronics article "CAN Bus Errors Explained" has an excellent section with practical experiments demonstrating these links. You don't need to perform the experiments, but reviewing their findings will be highly valuable for your work.

Conclusion

This lesson concludes our deep dive into the foundational layers of the CAN protocol. We have explored the sophisticated mechanisms that make CAN a robust and reliable network, a quality that is paramount in the automotive world.

Key Takeaways:

• CAN uses five error detection mechanisms: Bit, Stuff, Form, ACK, and CRC errors.
• Upon detecting an error, a node transmits an Error Frame to invalidate the message for all nodes on the network.
• The fault confinement system uses a Transmit Error Counter (TEC) and a Receive Error Counter (REC) to track the health of each node.
• Based on these counters, a node can be in one of three states: Error Active, Error Passive, or Bus-Off, preventing a single faulty node from disabling the entire network.
• Specific physical faults on the bus (e.g., bad termination, ID collisions) map to predictable CAN error types, which is essential knowledge for diagnostics and testing.

With this solid understanding of how a single CAN frame is reliably transmitted (or gracefully fails), we are now ready to move up the protocol stack. In our next module, we will begin exploring the Transport Layer with ISO-TP (ISO 15765-2), which enables the transmission of diagnostic messages that are much larger than the 8 bytes allowed in a single Classical CAN frame.