Errors and messages in CAN Bus
Blog under Errors and Messages in CAN Bus the subject “Data Communication”.
- Vishwakarma Institute of Technology, Pune.
- Instrumentation and Control Engineering(SY-SEDA).
- Mentor and Author:- Pramod M Kanjalkar(Sir).
- Team:- |Akanksha Barde| Niraj Shevkari | Gayatri Relekar| Rakesh Dindore| Prathamesh Thombare.
The CAN Bus
What is CAN?
CAN is short for ‘controller area network’. Controller area network is an electronic communication bus defined by the ISO 11898 standards. Those standards define how communication happens, how wiring is configured and how messages are constructed, among other things. Collectively, this system is referred to as a CAN bus.
CAN bus is a broadcast type of bus. This means that all nodes can “hear” all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages.
We’ll also discuss how the bus uses Non-Return To Zero (NRZ) with bit-stuffing. In this system, the modules are connected to the bus in a wired-and fashion: if just one node is driving the bus to a logical 0, then the whole bus is in that state regardless of the number of nodes transmitting a logical 1.
The CAN standard defines four different message types. The messages uses a clever scheme of bit-wise arbitration to control access to the bus, and each message is tagged with a priority.
CAN Messages
The CAN bus is a broadcast type of bus. This means that all nodes can ‘hear’ all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages.
The CAN messages
CAN uses short messages — the maximum utility load is 94 bits. There is no explicit address in the messages; instead, the messages can be said to be contents-addressed, that is, their contents implicitly determines their address.
Message Types
There are four different message types (or frames)on a CAN bus:
- The Data Frame
- The Remote Frame
- The Error Frame
- The Overload Frame
The Data Frame is the most common message type. It comprises the following major parts (a few details are omitted for the sake of brevity):
*the Arbitration Field, which determines the priority of the message when to or more nodes are contending for the bus. The Arbitration Field contains.
- For CAN 2.0A, an 11-bit Identifier and one bit, the RTR bit, which is dominant for data frames.
- For CAN 2.0B, a 29-bit Identifier (which also contains two recessive bits: SRR and IDE) and the RTR bit.
- the Data Field, which contains zero to eight bytes of data.
- the CRC Field, which contains a 15-bit checksum calculated on most parts of the message. This checksum is used for error detection.
- an Acknowledgement Slot; any CAN controller that has been able to correctly receive the message sends an Acknowledgement bit at the end of each message. The transmitter checks for the presence of the Acknowledge bit and retransmits the message if no acknowledge was detected.
The Remote Frame
The Remote Frame is just like the Data Frame, with two important differences:
- it is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and
- there is no Data Field.
The intended purpose of the Remote Frame is to solicit the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234.
Remote Frames can be used to implement a request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behaviour outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame, or to notify the local CPU instead.
There’s one catch with the Remote Frame: the Data Length Code must be set to the length of the expected response message. Otherwise the arbitration will not work.
Sometimes it is claimed that the node responding to the Remote Frame is starting its transmission as soon as the identifier is recognized, thereby “filling up” the empty Remote Frame. This is not the case.
Error Frame
If a transmitting or receiving node detects an error, this will cause the node to stop transmission and broadcast an error frame on the network, subsequently causing all other nodes on the bus to send error frames as well. An error frame consists of two fields, including an error flag field, with a maximum of 12 bits (six dominant and 6 recessive bits) and an error delimiter consisting of 8 recessive bits.
Error Frame consists of “6” dominant or recessive bits, depending upon the error state of the node which transmits it. It is transmitted by the node/s that detect/s any communication error, resulting in an immediate termination of transmission, and is retransmitted later. Again, this is all controlled by a controller, not application software.
Error Flag: Every CAN controller along a bus tries to detect errors within a message as error handling is built into the CAN protocol. Every CAN controller along a bus will try to detect errors within a message. If an error is found, the discovering node transmits an Error Flag, thus destroying the bus traffic. Using the error counters, a CAN node can detect faults and perform error confinement.
Overload Frame
If a CAN node receives messages faster than it can process them, an overload frame is used to inject an additional delay between data or remote frames. An Overload Frame has two fields, including an overload flag consisting of six dominant bits and an overload delimiter consisting of eight recessive bits.
Errors in CAN Bus
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.