CAN bus car
CAN concept
CAN is the abbreviation of Controller Area Network (CAN). It was developed by German BOSCH company , which is famous for R&D and production of automotive electronic products , and finally became an international standard ( ISO11898 ). It is the serial standard of ISO international standardization. communication protocol . It is one of the most widely used field buses in the world. In North America and Western Europe, the CAN bus protocol has become the standard bus for automotive computer control systems and embedded industrial control LANs, and has a J1939 protocol designed for large trucks and heavy machinery vehicles with CAN as the underlying protocol . In recent years, its high reliability and good error detection ability have been valued, and it is widely used in automotive computer control systems and industrial environments with harsh ambient temperatures, strong electromagnetic radiation, and large vibrations.
CAN's two ISO international standards:
1) ISO11898 : defines a high-speed CAN communication standard with a communication rate of 125 kbps to 1 Mbps. It belongs to a closed-loop bus with a transmission rate of up to 1 Mbps and a bus length of ≤ 40 meters.
2) ISO11519 : defines a low-speed CAN communication standard with a communication rate of 10-125 kbps , which belongs to an open-loop bus. When the transmission rate is 40kbps, the bus length can reach 1000 meters.
CAN type
1) High-speed CAN:
a. Provide baud rate from 5Kbit/s to 1Mbit/s according to the length of the cable.
b. The high-speed CAN network is terminated with a 120-ohm resistor at each network endpoint.
c. The silent level is 2.5V, and the upper and lower limits are 3.5V and 1.5V.
2) Fault-tolerant CAN:
a. Provide baud rate from 5Kbit/s to 125Kbits/s.
b. When dominant, it is 1V and 4V.
3) Single-wire CAN:
a. Provide baud rate from 5Kbit/s to 125Kbits/s.
b. The baud rate of single-wire CAN is generally 33.3KHz.
Automotive CAN network
Automotive CAN network
Automotive CAN bus
Composition of CAN
A frame of the CAN bus is mainly composed of frame information , frame ID and frame data .
1) Frame information : divided into four categories, standard data frame (gasoline vehicle, motor), standard remote frame (rare), extended data frame (most diesel vehicles, some gasoline vehicles), extended remote frame (rare).
2) Frame ID: It is a kind of "address" of CAN. A feature of CAN is the competition mechanism . The smaller the frame ID, the more right it has to occupy bus resources, and the more priority it will send.
CAN ID
DBC file: In the vehicle industry, if a standard interpretation is made for each frame ID and each frame data on the vehicle CAN bus, the formed file is a DBC file.
3) Frame data: Compared with the serial port, the frame data of CAN only has 8 bytes, that is, 64 bits , and there will be no more. But CAN FD solves the problem of only 8 bytes as a new bus.
4) Terminal resistance: CAN is the same as RS485. It is necessary to reduce the reflection of the differential signal at the terminal. If the resistance is not added to the two terminals, the signal will bounce back and affect the communication. There must be two terminal resistors on the CAN bus, with a resistance value of 120 ohms, connected in parallel, and one on the farthest terminal side. If there are multiple nodes, the terminal resistance should be appropriately increased.
5) Baud rate : Common vehicle baud rates are 500K, 250K, 125K, 100K.
CAN bus standard
ISO standard
The CAN standard is divided into two categories: the bottom layer standard (physical layer and data link layer) and the upper layer standard (application layer).
- ISO 11898-1 – CAN protocol
- ISO 11898-2 – CAN High Speed Physical Layer
- ISO 11898-3 – CAN Low Speed Fault Tolerant Physical Layer
- ISO 11898-4 – Time-triggered CAN
- ISO 11898-5 – "High Speed Media Access Unit in Low Power Mode" – currently in draft
- ISO 11519-2 - Obsolete, superseded by 11898-3.
- ISO 14230 - "Keyword Protocol 2000" - defines parts of non-CAN serial line diagnostics.
- ISO 15765 - the standard defining diagnostics on the CAN bus - is essentially the Keyword Protocol 2000 on the CAN bus.
- J1939 – The most widely used CAN-based high-level protocol for trucks and buses, defined by SAE. J1939 is divided into several parts, describing the physical layer, data link layer, network management and a large number of predefined messages.
- ISO 11783 – similar to J1939, but for the agricultural sector (such as tractors)
- ISO 11992 – defines the interface between trucks and trailers
- NMEA 2000 – J1939-based protocol used in the maritime sector. Defined by the NMEA committee.
If you don't specify which standard you're talking about, it usually defaults to the data link layer protocol defined by ISO 11898-1 and the physical layer defined by ISO 11898-2.
Underlying standard:
The underlying standards of CAN are basically the same, covering the physical layer and data link layer in the OSI model, and the corresponding relationship with the ISO/OSI model is shown in the following figure:
Correspondence
- ISO 11898-1: Data link layer protocol, describes the basic architecture of the CAN bus, and defines the communication methods of different CAN bus devices at the data link layer
- ISO 11898-2: High-speed CAN bus physical layer protocol, the maximum data transmission rate is 1Mbps, and the application is a two-wire balanced signal (CAN_H, CAN_L)
- ISO 11898-3: Defines the low-speed CAN bus (LS-CAN, Fault-Tolerant CAN) physical layer standard, with a data transmission rate of 5Kbps ~ 125Kbps. Fault-Tolerant means that when a transmission signal on the bus fails, it can also communicate by relying on another single signal
- ISO 11898-4: Defines the time-triggered mechanism (Time-Triggered CAN, TTCAN) in the CAN bus, defines the frame synchronization entity that cooperates with ISO 11898-1, and realizes the time-triggered communication method between automotive ECUs.
Upper standard:
Different application fields or manufacturers have different practices, and there is no uniform international standard
Comparison of upper layer protocols
CAN frame types (four frame types)
1) Data frame
A frame used by a sending unit to transmit data to a receiving unit.
The frame structure diagram of the data frame:
Data Frame
SOF: Indicates the start of the data frame; (1 bit), a dominant bit edge is sent, and the network node starts to synchronize
ID: 11 bits in standard format, 29 bits in extended format including Base ID (11 bit) and Extended IDr (18 bit), this section identifies the priority of the data frame, the smaller the value, the higher the priority;
RTR: remote transmission request bit, 0 means data frame, 1 means remote frame, that is to say, when RTR=1, the Data Field of the message frame is empty; (1 bit)
IDE: (1 bit) identifier extension bit, 0 indicates the standard format, 1 indicates the extended format; the extended frame and the standard frame format are different, and cannot exist in the same can network
DLC: data length code, 0-8 means the data length is 0~8 Byte; (4 bit)
Data Field: data field; (0~8 Byte)
CRC （15 bit）：
- Check field, encode all data from sof to data field
- Filled by the sender
- Check algorithm G(x) = x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1; (15 bit)
DEL: the implicit delimiter of the check field and response field; (1 bit)
ACK：（1 bit）
- Response field, to confirm whether the data is received normally. The so-called normal reception means that it does not contain filling errors, format errors, and CRC errors.
- The sending node sets this bit to 1, and the receiver confirms it, and gives a dominant bit 0 when receiving the message
- If a node does not confirm receipt of the message, the sender will report an error if it monitors this bit as an invisible bit
SRR: Substitute remote request bit, used in extended format, must be 1; (1 bit)
EOF: 7 consecutive recessive bits (1) indicate the end of the frame; (7 bit)
ITM（3 bit）：
- Interframe space, Intermission (ITM), also known as Interframe Space (IFS), has 3 consecutive recessive bits, but it does not belong to the data frame.
- Interframe space is a frame used to separate data frames and remote frames from preceding frames. Data frames and remote frames can separate this frame from any preceding frame (data frame, remote frame, error frame, overload frame) by inserting interframe space. Interframe space cannot be inserted before overload frames and error frames.
2) Remote frame
A frame used by a receiving unit to request data from a sending unit with the same identifier.
The frame structure of the remote frame is similar to that of the data frame, the difference is:
- 1. The RTR value of the data frame is "0", and the RTR value of the remote frame is "1".
- 2. There is no data block in the remote frame.
- 3. The DLC block of the remote frame indicates the length of data sent by the request sending unit.
format diagram
remote frame
When the data frame and the remote frame with the same identifier on the bus are sent at the same time, because the RTR bit of the data frame is dominant, the data frame will win the control right of the bus in the arbitration.
3) Error frame
Frame used to notify other units of an error when an error is detected.
The frame structure of an error frame consists of an error flag and an error delimiter.
Error flag: 6bit,
error flag
Error delimiter: composed of 8-bit recessive bits.
4) Overload frame
The receiving unit notifies the sending unit that it has not yet completed preparations for reception.
Two cases of sending overload frames:
1. The condition of the receiving unit requires the sending node to delay the transmission of the next data frame or remote frame.
2. A dominant bit is detected in the 3 bits of the Intermission.
Each node can send at most two overload frames continuously, and the overload frame is composed of an overload flag and an overload delimiter (8 recessive bits).
overload frame
Data frame and remote frame comparison:
Compare
CAN bus arbitration
Arbitration priority: the smaller the identifier value, the higher the priority of the message
Line and logic : Only when the nodes send are all recessive , the bus level is recessive
While sending data, all sending nodes also detect the level status on the bus, and compare the level on the bus with the level sent by itself bit by bit.
- 1) When 0 is sent, 1 appears: an error is reported.
- 2) Send 0 and appear 0: continue.
- 3) Send 1 and appear 1: Continue.
- 4) Sending 1 and appearing 0: the competition fails, and it becomes the receiver.
send self test
As shown in the figure below, the C node that failed the competition will automatically try to send again the first time it detects that the bus is idle.
CAN nodes A and C send data frames at the same time, the CAN bus is arbitrated according to the priority, and C loses power
CAN conditional access
Messages on the CAN bus are broadcast . Nodes can determine whether to receive the message by setting the filter code (Filter Code) and mask (Mask Code) in the controller, and then checking the identifier of the message on the bus. For the mask , "1" indicates that this bit is related to this node, and "0" indicates that this bit is not related to this node.
CAN-BUS data flow
STM32 can filter code
bit stuffing
The CAN bus adopts NRZ encoding, without a separate clock line, which has the advantage of high efficiency, but it is not easy to distinguish where the bit starts and where the bit ends. Therefore, in order to ensure sufficient level jumps during synchronous communication, a bit , that is, an inversion level is inserted after every 5 consecutive identical levels , and the receiving node automatically receives the message after receiving the message. Remove padding.
DataFrame Bit Stuffing Comparison Chart
Except for the CRC delimiter, ACK field and EOF in the frame, the bit stuffing mechanism is applied to the rest of the frame. In the field where the bit stuffing is applied, the detection of 6 consecutive dominant bits or recessive bits is regarded as an error report.
CAN error checking
CRC error
1) When sending a message, the sending node will calculate the Checksum value from the SOF bit of the data frame to the last bit of the data field according to a specific polynomial, and put the value in the CRC field of the data frame, and broadcast the data frame to the bus superior.
2) After receiving the data, the receiving node applies the same polynomial to calculate the Checksum value and compares it with the received Checksum value. If the two are consistent, it will be received normally; if not, the message will be discarded, and an error frame will be sent to request the sending node to retransmit the message.
Response error (ACK Error)
The receiver will give a dominant level in the ack response bit after receiving the message, and if the sender detects that the bit is recessive, it will report an error.
Format error (Form Error)
Errors detected when the format opposite to the fixed-format bit field is detected, such as detecting whether a dominant bit appears in the CRC delimiter and ack delimiter and the eof area.
Bit Error
Compare the output level with the bus level (excluding stuffing bits), and detect the error when the two levels are different. If a dominant bit is sent, but the bus is a recessive bit, an error will be reported.
Stuff Error
An error detected when 6 bits of the same level are detected consecutively within a segment requiring bit stuffing.
CAN bus error detection mechanism
Each node controller on the CAN bus will detect whether the message is wrong . If the node finds that the message is wrong, it will send an error flag, thus interrupting the normal data transmission on the bus. Other nodes on the bus that have not found the original message error will take necessary measures after receiving the error flag, such as discarding the current message on the bus.
There are two error status counters inside the CAN node:
- 1) TEC /Transmit Error Counter, sending error status counter, once an error occurs, the counter value +8
- 2) REC /Receive Error Counter, receiving error status counter, once an error occurs, the counter value +1
- 3) If the message is successfully sent or received once, the corresponding TEC or REC value will be -1
error count
The CAN specification defines 3 error states for nodes:
- 1) Active error: normal state, in this state, the node can send all types of frames, including error frames; it will actively report the error after finding the error.
- 2) Passive error: the node can send all frames except the error frame; the TEC or REC count exceeds 127 and enters this state; at this time, the node will only send 6 recessive bits after finding the error, and will not broadcast the error . And, when sending continuous frames, there must be an 8-bit delay time between them.
- 3) The bus is off: the node is isolated from the bus by the controller; or the TEC is greater than 255, it will enter this state and needs to be restarted, or wait for 128 11-bit recessive bit levels.
CAN bus error detection mechanism
Introduction to CAN bus protocol.pdf
CAN bus C source code and data.rar
CAN bus C source code and data, can analyzer bus motor synchronous start source program
CAN bus protocol application manual.pdf
CAN bus protocol application manual
can-utils.zip
CAN tools, including basic tools for displaying, recording, generating and replaying CAN traffic, CAN core gateway configuration, CAN bus measurement and testing, ISO-TP tools, log file converter, serial line specification configuration, CMake project generator, etc. source code
CAN Bus Shield - MCP2515&MCP2551.zip
Can bus protocol source code and application case code based on arduino