CAN Protocol: Architecture & Mechanisms

1. What is CAN and Why is it Essential in Automotive?

Before CAN, every electronic device in a car (like power windows, engine sensors, or the dashboard) required direct, point-to-point wiring. This led to complex, heavy, and expensive wiring harnesses. CAN was developed by Bosch in the 1980s to solve this problem by allowing multiple Electronic Control Units (ECUs) to communicate over a shared, two-wire bus.

It's a multi-master, message-broadcast system known for its high speed and exceptional reliability, making it ideal for safety-critical automotive applications. The video below provides an excellent introduction to what CAN is and why it's so widespread.

As the video explained, CAN's reliability comes from its physical design. Differential signaling makes it highly resistant to the electromagnetic interference (EMI) common in a vehicle's environment. The difference in voltage between the two wires, not the voltage itself, determines the logic level, effectively canceling out noise that affects both wires equally.

2. Bus Arbitration: The Core of CAN

With multiple ECUs on a shared bus, a critical question arises: what happens if two or more nodes try to send a message at the same time? This is where CAN's most elegant feature comes into play: non-destructive bit-wise arbitration.

The CAN protocol is a type of CSMA/CD+AMP (Carrier-Sense, Multiple Access with Collision Detection and Arbitration on Message Priority). Here's what that means:

• Carrier-Sense: A node only tries to transmit if the bus is idle.
• Multiple Access: Many nodes can access the bus.
• Collision Detection & Arbitration: If multiple nodes start transmitting simultaneously, a collision is detected, but it's resolved through an arbitration process based on message priority. The message is not destroyed.

The key principles are:

1. Dominant vs. Recessive Bits: A logic '0' is a dominant bit, and a logic '1' is a recessive bit. If one node sends a dominant bit and another sends a recessive bit, the bus state will be dominant. Think of it as a "wired-AND" logic gate.
2. Message Identifiers: Every CAN message begins with an identifier. This identifier serves a dual purpose: it describes the message content (e.g., "engine RPM," "wheel speed") and sets its priority.
3. The Arbitration Process: When multiple nodes start transmitting, they send their identifier bit by bit, while simultaneously monitoring the bus. If a node transmits a recessive '1' but sees a dominant '0' on the bus, it knows it has lost arbitration. It immediately stops transmitting and becomes a receiver, listening to the winning message. The node that transmitted the dominant '0' doesn't even know a conflict occurred and continues sending its message.

Because a '0' wins over a '1', the message with the numerically lowest identifier has the highest priority.

The following resources provide a clear, step-by-step visualization of this process.

Now, let's see a more detailed, bit-by-bit example of arbitration in action.

This non-destructive arbitration is what makes CAN suitable for real-time control. High-priority messages (like airbag deployment signals or brake commands) are guaranteed to get through with minimal latency, even on a busy bus.

3. The Structure of a CAN Message Frame

Now that you understand the role of the identifier in arbitration, let's look at the complete structure of a standard CAN message, also known as a Data Frame.

Let's break down these fields:

• Start of Frame (SOF): A single dominant bit that marks the beginning of a message and synchronizes all nodes.
• Arbitration Field:
  • Identifier (11 bits): This is the message priority we just discussed.
  • Remote Transmission Request (RTR): A dominant bit for a Data Frame (transmitting data). A recessive bit here would signify a Remote Frame, which is used to request data from another node.
• Control Field:
  • Identifier Extension (IDE): A dominant bit for Standard CAN (11-bit ID). A recessive bit here would indicate an Extended CAN frame (29-bit ID).
  • Data Length Code (DLC): A 4-bit value indicating the number of data bytes in the message (0 to 8).
• Data Field: Contains the actual data payload, from 0 to 8 bytes.
• Cyclic Redundancy Check (CRC) Field: A 15-bit checksum calculated by the transmitter. Receivers perform the same calculation, and if the results don't match, an error is flagged.
• ACK (Acknowledge) Field: A 2-bit field. The transmitter sends a recessive bit in the first slot. Any node that correctly received the message will overwrite this slot with a dominant bit, confirming reception.
• End of Frame (EOF): A sequence of 7 recessive bits marking the end of the message.

This video from Texas Instruments provides a detailed walkthrough of each field in a CAN frame.

4. Robust Error Handling

CAN's reputation for reliability is built on its sophisticated, multi-layered error handling mechanisms. It's designed not only to detect errors but also to confine faults, preventing a single malfunctioning node from taking down the entire network.

The protocol specifies five types of error detection:

1. Bit Monitoring: The transmitter reads back the bit it's sending. If the read value doesn't match the sent value (and it's not during arbitration), a Bit Error is flagged.
2. Bit Stuffing: As you saw in the video, if a receiver sees 6 consecutive bits of the same polarity, it flags a Stuff Error, as this violates the bit stuffing rule.
3. Frame Check: Certain fields in the frame have a fixed format (e.g., CRC Delimiter, ACK Delimiter, EOF). If a receiver detects an invalid bit in these fields, it flags a Form Error.
4. Acknowledgement Check: If the transmitter does not see a dominant bit in the ACK slot, it knows no node received the message correctly and flags an Acknowledgement Error.
5. Cyclic Redundancy Check (CRC): If a receiver's calculated CRC doesn't match the CRC in the message, it flags a CRC Error.

When any node detects an error, it immediately transmits an Error Frame (a sequence of 6 dominant bits that deliberately violates the bit stuffing rule) to destroy the message on the bus and notify all other nodes. The original transmitter then automatically attempts to resend the message.

To prevent a faulty node from continuously disrupting the bus, each node maintains Transmit and Receive Error Counters. Based on the value of these counters, a node can be in one of three states:

• Error Active: The normal state. The node participates fully in communication, including sending Active Error Frames when it detects a fault.
• Error Passive: After its error counter exceeds a limit (127), the node can still transmit and receive but sends Passive Error Frames (6 recessive bits) which do not disrupt other bus traffic. It signals its own faulty state without halting communication for others.
• Bus Off: If the transmit error counter exceeds a higher limit (255), the node takes itself offline completely. It is not allowed to send anything on the bus until it is reset by the host microcontroller.

This error handling architecture is foundational to CAN. For a more detailed text-based explanation, please review the following resource.

5. Controller vs. Transceiver

Finally, it's important to understand the two hardware components that make up a CAN node.

• CAN Controller: This is a digital peripheral, usually integrated into the microcontroller (like your STM32). It handles the protocol logic: framing messages, arbitration, error counting, message filtering, etc. It works at the data-link layer.
• CAN Transceiver: This is an external IC (like the TJA1050 in your kit). It's a physical layer device that interfaces between the controller's single-ended logic (TX/RX pins) and the physical two-wire differential bus (CANH/CANL). It converts the digital signals into the appropriate voltage levels for dominant and recessive states.

Conclusion

In this lesson, you've explored the fundamental architecture of the CAN protocol, a cornerstone of automotive engineering.

Key Takeaways:

• CAN is a robust, multi-master broadcast bus that uses differential signaling for noise immunity.
• Bus access is managed by non-destructive bit-wise arbitration, where messages with lower-value identifiers have higher priority and win access without data loss.
• A CAN data frame is a structured message containing an identifier, control information, a data payload (0-8 bytes), and fields for error checking and acknowledgement.
• CAN features multiple layers of error detection (CRC, ACK, Bit Monitoring, etc.) and fault confinement (Error Active/Passive/Bus Off states) to ensure network reliability.
• A CAN node consists of a controller (protocol logic) and a transceiver (physical layer).

You now have the theoretical knowledge to understand how and why CAN works. In our next lesson, we will get practical. You will connect your CAN transceiver to the STM32, learn how to calculate and configure the bit timing registers, and prepare your project to send and receive your first CAN message.