The CAN protocol is the most important very less or ignorable errorless protocol. CAN protocol is also having multiple methods to prevent the error Like other protocols. You would have learned different methods for error in your engineering education time period. Basically, these methods are used in every protocol. But we are sometimes thinking it is difficult, because of ignorance in our engineering. If you will really trying to communicate in between the two or more processors or machines using any protocol, obviously you will face a lot of problems and you need to fix it to reduce the error in data communication.
Types of Error In CAN Protocol
CAN protocol is having multiple methods that can detect the different errors in CAN protocol. The CAN-FD is also having the same types of error. There are 5 types of error in CAN protocol. In each CAN controller, it will have an error detection module that can detect the errors as:
- Bit Error
- ACK Error
- Stuff Error
- CRC Error
- Form Error
Among the above 5 types of error, if any error detects by the CAN controller, it notifies the bus by sending a flag called CAN error frame.
CAN Protocol Bit-Error
Whenever a node sending by the transmitter unit with any bit on the CAN bus, it also monitors or receives the same data bit by its receiver driver. The ECU or node must detect the bit error if there is a difference between the transmitted bit and received bit in the CAN frame. That means if the Tx Bit is not equal to Rx bit then it will flag an error and send an error frame on the CAN bus.
An exception in CAN protocol is the sending of a recessive bit during the stuffed bit-stream of the Arbitration field or during any ACK Slot; in this case, no Bit error occurs when a dominant bit is monitored. If a transmitter sending a PASSIVE Error Flag and detecting a dominant bit, it does not interpret this as a Bit error. The bit error is one of the high priority CAN protocol error types. If the bit error;
- Detects in the CAN identifier field, it doesn’t send any error frame, instead, it stops sending a data frame for arbitration purposes.
- Detects in ACK bit, it considers as an acknowledgement signal for that transmitter.
- Does not detect an ACK bit, then the transmitter node detects it as ACK error instead of bit error.
CAN Protocol ACK Error
The CAN data frame is having consists of the ACK field with 2-bits. The first bit is the ACK bit and the second one is the ACK delimiter bit. Basically, after the completion of the data field, the Transmitter ECU makes the bus recessive. But the receiver driver of the Transmitter ECU will be monitoring this bit for detecting the ACK signal. Basically, bit monitoring happened for bit error, but here it is a special case where if the bit error occurs then the transmitter ECU will understand that the receiver ECU received the data successfully. if no bit error then there is an ACK error because of no data received by any ECU or node. The ACK error is one of the high priority CAN protocol error types.
CAN Protocol Stuff Error
The bit stuffing is a method of error detection in CAN protocol. This stuff check serves to check the bitstream on the CAN bus. Basically, this standard specifies the CAN protocol specification. When five consecutive bits of the same level have been transmitted by a node, it will add a sixth bit of the complementary level to the outgoing bitstream. The receiver should also remove this 6th complimentary from the real data. This method is basically called an NRZ-5 method. This is basically used to avoid the excessive DC components on the CAN bus, but it also gives the receivers an extra opportunity to detect the errors; if it detects more than 5 consecutive homogenious recessive or dominant bits.
This is used in the CAN network for synchronization purposes. To know more about it you can ask your query in our PiEST Forum. if more than five homogeneous contiguous bits are received by the receiver, then the receiver ECU will detect the bit stuff error. The STUFF error is one of the high priority CAN protocol error types.
CAN Protocol CRC Error
The CAN data or remote frame having consists of a 15-bit CRC calculated by the transmitter. When the receiver receives this frame, it will also receives that CRC data field sent by the transmitter ECU. At the same time, the receiver will also calculate a CRC by using the same logic as the transmitter has done it. So after the receiver calculates CRC, the receiver CAN controller will compare both the CRC. If it is same then there is no CRC error, otherwise it informs a CRC error to the CAN controller. Then the CAN controller flags a CRC error by sending an error frame on the CAN bus.
Basically, the CRC gets calculated by the polynomial calculation. The polynomial R(x) associated with the arriving data or remote frame should equal a multiple of the generator polynomial G(x) specified by ISO 11898-1 standard. If there is no CRC error, then the data or remote frame was corrupted during its transmission. The CRC error is one of the high priority CAN protocol error types.
CAN Protocol Form Error
This type of error is basically used for the purpose of the frame check. In CAN frame, some parts of its message have a fixed format. That means the CAN standard ISO-11898 defines exactly what levels must occur and when. These are the CRC Delimiter, ACK Delimiter, End of Frame, and also the Intermission fields, but there is some extra special error checking rules for that. The CAN standard defines recessive all these bits, so if any of these bits detects dominant, it flags a form error. The FORM error is one of the high priority CAN protocol error types.
