Embedded Development – Detailed Explanation and Application of CAN Protocol

Embedded Development - Detailed Explanation and Application of CAN Protocol

Click the blue text

Follow us

Bit Time and Bit Synchronization in CAN Communication

In CAN communication, Bit Time refers to the time required to transmit one bit on the bus, which is the reciprocal of the CAN bus communication rate (baud rate). CAN communication ensures reliable data transmission by sampling and synchronizing the signal within the bit time.
Bit time is divided into several segments, each serving a specific function to maintain the clock synchronization of the CAN bus and ensure the accurate transmission of signals.
Composition of Bit Time
Bit time consists of the following four segments:
1. Synchronization Segment:
  • This segment is the first part of the bit time, with a fixed length of 1 time quantum (Time Quantum, TQ).
  • It is used to detect edges (level changes) on the CAN bus, from dominant bit (Dominant, logical 0) to recessive bit (Recessive, logical 1), or vice versa.
  • By detecting the bit edge, CAN nodes can maintain synchronization with the bus.
2. Propagation Segment:
  • This segment compensates for the physical delay of the signal from one node to another. The delay is determined by physical factors such as line length and signal propagation speed.
  • Its length can be configured, typically ranging from 0 to 8 time quanta.
3. Phase Segment 1 (PHASE_SEG1):
  • This segment allows for early adjustment of the clock based on the received signal (bit synchronization). If the sampling point is slightly off, this segment can be adjusted for re-synchronization.
  • Its length can be configured, usually between 1 and 8 time quanta.
4. Phase Segment 2 (PHASE_SEG2):
  • This segment is used for delayed adjustment of the clock after sampling. If a signal change is detected on the bus, synchronization recovery can be performed through this segment.
  • Its length can be configured, typically between 1 and 8 time quanta.
Sampling Point
  • The sampling point is the moment when the bus level is detected within the bit time, usually located at the end of the bit time.
  • Bit time is divided into different segments, and the sampling point is usually placed at the end of Phase Segment 1 for optimal signal sampling.
  • The choice of sampling point location greatly affects the stability and error rate of CAN communication. The ideal sampling point is typically set between 75% and 87.5% of the bit time.
Calculation Formula for Bit Time
The Bit Time (t_BIT) duration depends on the baud rate of the CAN bus. Bit time is the reciprocal of the baud rate, with the formula:
Embedded Development - Detailed Explanation and Application of CAN Protocol
For example, if the baud rate is 500 kbps (500,000 bits/second), the bit time is:
Embedded Development - Detailed Explanation and Application of CAN Protocol
Time Quantum (TQ)
Bit time consists of multiple Time Quanta (TQ), which is the basic time unit of the CAN controller. One bit time typically contains 8 to 25 time quanta, and the length of TQ is determined by the clock frequency of the CAN controller and the baud rate prescaler.
Each time quantum TQ is calculated by the CAN controller based on its internal clock frequency and prescaler. The formula is as follows:
Embedded Development - Detailed Explanation and Application of CAN Protocol
Where:
  • f_CAN: Input clock frequency of the CAN controller.
  • BRP (Baud Rate Prescaler): Baud rate prescaler, which can be configured via registers.
Illustration of Bit Time Segments
Bit time can be understood according to four segments, each containing a certain number of time quanta (TQ):

Embedded Development - Detailed Explanation and Application of CAN Protocol

Bit Synchronization Mechanism
Since the CAN bus is a multi-node communication network, each node’s clock may differ slightly, so synchronization must be maintained through a bit synchronization mechanism. The synchronization mechanism is based on the following methods:
1. Hard Synchronization:
When the bus is idle (recessive bit), upon detecting the first dominant bit (SOF frame start bit), all nodes immediately perform hard synchronization, adjusting the time to the edge of that dominant bit.
2. Re-Synchronization:
During data frame transmission, if a node detects a bit edge offset, it can re-synchronize by adjusting Phase Segment 1 and Phase Segment 2 to ensure the next bit’s sampling point is accurate.

Arbitration Rules in CAN Communication

The arbitration rules of CAN (Controller Area Network) communication determine which node can gain control of the bus for data transmission when multiple nodes share the same bus. Since CAN bus operates in a multi-master architecture, multiple nodes can attempt to send data simultaneously. The arbitration process ensures that no conflicts occur, and higher priority messages are transmitted first.
Basic Principles of Arbitration Rules
The CAN bus employs a mechanism called non-destructive bit arbitration based on the Message Identifier (ID) priority. The smaller the message ID value, the higher the priority.
The basic principle of the arbitration process is as follows:
  1. When multiple nodes start sending frames simultaneously, they perform bit-level arbitration based on each frame’s Identifier (ID).
  2. The CAN bus is a wired-AND structure, with two levels on the CAN bus: dominant level (Dominant, logical 0) and recessive level (Recessive, logical 1). The dominant level has a higher priority than the recessive level.
  3. Each node listens to the bus while sending. If a node detects the bus level as dominant while sending a recessive bit, it knows that it has lost arbitration to another node and immediately stops sending.
  4. The arbitration process occurs bit by bit until only the node with the highest priority remains to continue sending, while other nodes drop out of the competition and wait for the next idle bus to attempt transmission.
Specific Steps of the Arbitration Process
1. Start Sending:
Each node begins sending data frames simultaneously, with each frame starting with SOF (Start of Frame), followed by the identifier.
2. Bit-by-Bit Arbitration:
Starting from the most significant bit (MSB) of the identifier, each node sends the bits in its identifier.
All nodes listen to the bus level simultaneously. When a node sends a recessive bit (logical 1) and detects the bus level as dominant (logical 0), it knows that a higher priority message is being sent and stops sending.
3. End of Arbitration:
Eventually, only the node with the highest priority remains on the bus during the arbitration process, while other nodes wait for the bus to become idle before attempting to send again.
Example of Arbitration
Suppose there are three nodes that simultaneously attempt to send frames with different identifiers:
Node A’s identifier: 1001010
Node B’s identifier: 1000110
Node C’s identifier: 1001110
The arbitration process is as follows:
  • After all three nodes start sending SOF, they begin to send their identifiers.
  • All nodes’ first bit is 1 (dominant), so they continue sending.
  • The second bit is also 0, and all nodes continue sending.
  • The third bit is 0, and they continue sending.
  • When it comes to the fourth bit, Node A sends 1 (recessive), while Nodes B and C send 0 (dominant). Since dominant has higher priority than recessive, Node A detects the dominant level on the bus and knows it has lost arbitration, thus stopping its transmission.
  • Next, Nodes B and C continue arbitration. For the fifth bit, Node B sends 1 (recessive), and Node C sends 1 (recessive), both continue.
  • For the sixth bit, Node B sends 0 (dominant), and Node C sends 1 (recessive). Node C detects the dominant level, thus losing arbitration and stopping its transmission.
Ultimately, Node B successfully arbitrates and continues sending its data, while Nodes A and C will attempt to send again once the bus is idle.
Characteristics of Arbitration
1. Non-Destructive Arbitration:Even if multiple nodes send simultaneously, the data on the bus is not corrupted because nodes that lose arbitration will actively stop sending, allowing higher priority nodes to continue sending their frames, ensuring data transmission integrity and collision-free operation.
2. Priority Determines Transmission Order:The message identifier determines the priority; a smaller value (i.e., more dominant bits) indicates a higher priority, allowing higher priority nodes to always send first.
3. Real-Time Assurance:Through the arbitration mechanism, urgent messages (high priority) can interrupt the transmission of non-urgent messages while the bus is occupied, ensuring real-time transmission of high-priority data.
The arbitration rules in CAN communication are based on non-destructive bit-level arbitration, ensuring that the highest priority node can successfully gain control of the bus, while other nodes automatically stop sending upon detecting loss of bus priority. Through this mechanism, the CAN bus can avoid conflicts under multi-node competition, ensuring reliable data transmission and real-time assurance.

Error States and Error Detection Mechanisms in CAN Communication

The error states and error detection mechanisms in CAN communication are key parts to ensure the reliability and safety of bus data transmission. Since CAN is a real-time communication protocol with multiple nodes sharing the same bus, it possesses a comprehensive error detection and handling mechanism to avoid the impact of data transmission errors on the system.
1. Types of Errors in CAN
The CAN protocol defines several types of errors, primarily including:
(1) Bit Error
  • A bit error occurs when the data bit sent by a node does not match the actual level on the bus.
  • If a node detects the bus as a recessive bit (logical 1) while sending a dominant bit (logical 0), or vice versa, a bit error is triggered.
  • Note: During arbitration, nodes may detect different bits but this is not considered an error as it is part of the arbitration mechanism.
(2) Stuff Error
  • The CAN protocol requires that after sending five consecutive identical bits, an opposite bit must be inserted as a stuffing bit to ensure synchronization on the bus.
  • If a node detects six consecutive identical bits (i.e., no stuffing bit inserted) during reception, a stuff error occurs.
(3) CRC Error (Cyclic Redundancy Check Error)
  • The CRC field is used to verify whether the data in the frame has been transmitted correctly.
  • The sending node calculates a CRC check value and appends it to the frame. The receiving node recalculates the CRC based on the received frame, and if the result does not match the CRC value in the frame, a CRC error is triggered.
(4) Form Error
  • Each part of the CAN frame has strict format requirements, including the start bit, control field, data field, CRC field, acknowledgment field (ACK), end bit, etc.
  • If any part of the frame does not comply with the required format (for example, if illegal levels appear in the SOF, EOF, or ACK fields), a form error occurs.
(5) ACK Error
  • After the CAN frame transmits data, the receiving node must send a dominant bit in the Acknowledgment Field (ACK Field) to indicate that it has received the data.
  • If the sending node does not detect a dominant bit in the ACK slot (ACK slot), it triggers an ACK error.
2. Error States
The CAN protocol uses error counters to track the occurrence of errors, determining the node’s error state. There are two error counters:
  • Transmit Error Counter (TEC): Records the number of transmission errors.
  • Receive Error Counter (REC): Records the number of reception errors.
Based on the values of the error counters, nodes can enter different error states:
(1) Error Active State
  • Initially, all nodes are in the error active state.
  • When a node is in this state, it can send active error frames to notify other nodes of the error. An active error frame consists of 6 consecutive dominant bits.
(2) Error Passive State
  • When either the transmit error counter or receive error counter exceeds 127, the node enters the error passive state.
  • In the error passive state, the node can only send passive error frames, which consist of 6 consecutive recessive bits, and will not affect bus arbitration.
  • Nodes in the error passive state do not actively interfere with the bus, preventing impact on the communication of other nodes.
(3) Bus Off State
  • If the transmit error counter (TEC) exceeds 255, the node enters the bus off state and stops participating in bus communication.
  • Nodes in the bus off state cannot send or receive any messages, but their internal logic continues to operate. This state aims to prevent faulty nodes from continuing to affect other nodes on the bus.
  • Nodes in the bus off state need to be reset via software or hardware to restore normal communication.
3. Error Detection Mechanisms in CAN
The CAN protocol employs various error detection mechanisms to ensure the accuracy and reliability of data transmission. The main error detection mechanisms in CAN are as follows:
(1) Bit Monitoring
  • The sending node monitors the bus level in real-time while sending each bit. If it detects that the sent bit does not match the actual bus level, a bit error is triggered.
  • The bit monitoring mechanism can effectively detect errors in single bit transmissions.
(2) Bit Stuffing Detection
  • The CAN protocol requires that after sending five consecutive identical bits, an opposite bit must be inserted. The receiving node checks whether this rule has been followed.
  • If stuffing bits are not inserted as required, a stuff error is triggered.
(3) Frame Check
  • The receiving node performs format checks on the fixed fields of the CAN frame (such as SOF, EOF, ACK, etc.). If the format does not comply with protocol requirements, a form error is triggered.
(4) CRC Check
  • The CRC field of the CAN frame is used to detect errors in data transmission. The receiving node calculates the CRC value of the data and compares it with the CRC value in the frame. If they do not match, a CRC error is triggered.
(5) ACK Check
  • When the receiving node successfully receives data, it sends a dominant bit in the ACK field. The sending node checks this field, and if no dominant bit is received, an ACK error is triggered.
4. Error Handling Process
1. Error Detection:
When a node detects an error, it immediately stops the transmission of the current frame and sends an Error Frame to notify other nodes of the error.
2. Sending Error Frames:
Error frames consist of two parts: an active error flag (Error Flag) and an error delimiter (Error Delimiter).
  • Active Error Frame: Consists of six consecutive dominant bits, indicating a severe error.
  • Passive Error Frame: Consists of six consecutive recessive bits, indicating that the node is in an error passive state.
Error frames forcefully interrupt the current transmission on the bus with dominant levels, notifying all nodes to restart the transmission process.
3. Updating Error Counters:
After sending or receiving an error frame, nodes update their transmit or receive error counters based on the error type. When the error counter exceeds a certain threshold, the node’s state changes from error active to error passive, and in severe cases, it enters the bus off state.

Embedded Development - Detailed Explanation and Application of CAN Protocol

Embedded Development - Detailed Explanation and Application of CAN ProtocolEmbedded Development - Detailed Explanation and Application of CAN Protocol

Source: Trump. Yang

*Disclaimer: This article is original or forwarded by the author. If it inadvertently infringes upon any party’s intellectual property rights, please inform us for deletion. The above images and text are sourced from the internet. If there is any infringement, please contact us promptly, and we will delete it within 24 hours. The content of the article reflects the author’s personal views, and the Automotive Ethernet Technology Research Laboratory reprints it solely to convey a different perspective, which does not represent the Automotive Ethernet Technology Research Laboratory’s endorsement or support of that view. If there are any objections, please feel free to contact the Automotive Ethernet Technology Research Laboratory.

Original link:
https://blog.csdn.net/weixin_46999174/article/details/142322734

Leave a Comment