How to perform CRC error detection during CAN bus communication
In the practical application of fieldbus communication and control, the industrial application environment is often extreme temperature and electromagnetic noise or other harsh environment. It is very important for the system to work properly under such conditions. Imagine if the production line equipment sends it. The location information has an error during the transmission process, which may cause production defects, which may result in equipment damage or even personal injury.
The CAN controller has complete error detection capability during CAN bus communication, including: bit error detection, format error detection, fill error detection, response error detection and CRC error detection. As an important error detection method, CRC error detection is the basis for the receiving node to judge the integrity of the CAN frame information and confirm the response to the bus.
First, the common verification method
1. The simplest check is to actively read back after the data is sent. The result is consistent and the transmission is successful. It is obvious that the communication method is very intuitive and very accurate, but the data transfer volume is doubled due to the readback operation. That is, the transmission has high bandwidth requirements and low efficiency;
2. Parity is the use of an extra bit in the transmission to record whether the number of 1 in the binary number of the transmission data is odd or even. This scheme is suitable for most hardware, and the transmission overhead is moderate, so it is widely used, for example, common. Serial communication
3. Accumulation and verification, the principle of the algorithm is to accumulate data one by one to obtain a value. The receiver also accumulates the data while receiving the data and finally compares it with the summed sum sent. The algorithm is simple to calculate, no matter in Hardware or software implementation can guarantee high efficiency, and is often used for low-speed serial data communication check and chip integrity judgment;
4. CRC test, the algorithm is based on the result of a polynomial division, which has dozens of versions according to the number of bits and polynomial changes. It is simple in hardware implementation, strong in bit reversal debugging capability and moderate in computational cost. Advantages are widely used in digital network transmission and data storage fields, such as disk data verification, USB, GSM/CDMA communication, compression/decompression data integrity check of RAR and ZIP files frequently encountered in computer applications. algorithm;
5. MD5 and SHA are the summary of information digest. The data digest algorithm is also called hash algorithm and hash algorithm. The digest algorithm is used for occasions with large data volume. It extracts fingerprint information from all data to realize data signature, data integrity check and other functions. Due to its irreversibility, it is sometimes used as encryption for sensitive information, such as content protection of software registration authorization files, and frequent encounters. The large files downloaded to the Internet (for example, ISO images of size to GB) usually have MD5, SHA1 and other information to facilitate the user to check the integrity of the transmitted data.
Second, the CRC test in the CAN frame
1. Location of the CRC field in the CAN frame
As shown in the orange block of Figure 1, in a traditional CAN frame structure, the CRC field is placed before the end of the data response and the same position is for the CAN FD. This information is invisible to the user application interface. The corresponding CRC data is displayed from the bus analog waveform through the CANscope bus analyzer decoding window or an oscilloscope with CAN protocol decoding capability, as shown in Figure 2.
2. CRC generation in CAN frames
In the classic CAN, using a 15-bit CRC, the CRC calculation can be done in hardware using shift and XOR operations, while the CAN FD specification extends the frame data length for CAN FD frames with a data length of 16 bytes or less. A 17-bit CRC is used, and a 21-bit CRC is used for CAN FD frames with a data length greater than 16 bytes. Several versions of the CRC generation polynomial g used in the CAN bus are organized as shown in Table 1.
3. How does CRC complete the verification work?
The security check of the CAN frame based on the CRC polynomial is that the transmitter calculates the check value based on the transmitted bits and provides the result in the CAN frame structure CRC field. The receiver uses the same polynomial to calculate the check value of the bit seen on the bus, and compares the self-calculated check value with the received calibration value. If it matches, the frame is considered to be correctly received, and the receiving node is in the ACK slot. The dominant state is sent to override the implicit state of the transmitter. In the case of a mismatch, the receiving node sends an error frame after the ACK delimiter.
At present, the CAN FD controller CRC check implementation process is relatively complicated. In a CAN bus network, after the frame start is detected, all nodes start to use the three sets of polynomials g15, g17 and g21 to calculate the CRC sequence synchronously. Including the transmitting node, since the calculation of the CRC is affected by the CAN frame type and the DLC length, the corresponding CRC generation sequence is selected until the control field of the CAN frame and the DLC is confirmed, and the determined CRC sequence is adopted in the frame structure. For sending or for receiving comparisons.
4. ISO CAN FD, non-ISO CAN FD compatibility issues related to CRC
There are two versions of the current CAN FD protocol. To improve fault (error) detection, the new version introduces a 3-bit pad counter and an additional parity bit. In addition, the CRC calculation method has also changed. These improvements make the latest CAN FD protocol incompatible with the original CAN FD protocol developed by Bosch. The ISO-Responsible Working Group has completed its documentation and has submitted it to the DIS (International Standard Draft) for voting procedures.
To avoid misunderstanding, CiA recommends the terms “ISO CAN FD” and “non-ISO CAN FD”. All products complying with ISO 11898-2:2015 shall be referred to as "ISO CAN FD". Products that implement Bosch's original CAN FD protocol should be named "non-ISO CAN FD". The main purpose of this product in this transition phase is for pre-assessment and development, and all products will comply with ISO standards in the future.
Please note that some of the components or tools provided by some vendors have been for the non-ISO CAN FD protocol, including some CAN FD products currently on sale. CiA recommends using only ISO CAN FD products for design and development, but you can continue Use non-ISO CAN FD for evaluation and pre-development, as protocol changes are not visible to the user interface, but note that non-ISO CAN FD and ISO CAN FD interface devices cannot be mixed with the same network, which can cause CAN bus errors. Unable to complete transmission and reception. If only sending or receiving traditional CAN frames will not be affected, it is fortunate that some device vendors provide components or tools that allow users to choose to support ISO or non-ISO mode. The land helps you get the job done during the transition period.
The traditional CAN and the current CAN FD verification mechanism ensure that the corrupted frame data in the transmission process will hardly be received and the response is successful, which can effectively prevent the physical layer transmission error, so that the user interface does not need to pay attention to the frame transmission data correctly. Sex.