16.2.5 Errors
The CAN protocol signals any errors immediately as they occur. Three error detection mechanisms are implemented at the
message level and two at the bit level:
16.2.5.1 Error at Message Level
●
Cyclic redundancy check (CRC)
The CRC safeguards the information in the frame by adding redundant check bits at the transmission end. At the
receiver these bits are re-computed and tested against the received bits. If they do not agree there has been a CRC
error.
●
●
Frame check
This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and
the frame size. Errors detected by frame checks are designated “format errors”.
ACK errors
As already mentioned frames received are acknowledged by all receivers through positive acknowledgement. If no
acknowledgement is received by the transmitter of the message an ACK error is indicated.
16.2.5.2 Error at Bit Level
●
Monitoring
The ability of the transmitter to detect errors is based on the monitoring of bus signals. Each node which transmits
also observes the bus level and thus detects differences between the bit sent and the bit received. This permits
reliable detection of global errors and errors local to the transmitter.
●
Bit stuffing
The coding of the individual bits is tested at bit level. The bit representation used by CAN is “Non Return to Zero
(NRZ)” coding, which guarantees maximum efficiency in bit coding. The synchronization edges are generated by
means of bit stuffing.
16.2.5.3 Error Signalling
If one or more errors are discovered by at least one node using the above mechanisms, the current transmission is aborted
by sending an “error flag”. This prevents other nodes accepting the message and thus ensures the consistency of data
throughout the network. After transmission of an erroneous message that has been aborted, the sender automatically re-
attempts transmission.
16.3 CAN Controller
The CAN controller implemented into ATmega16/32/64/M1/C1 offers V2.0B active.
This full-CAN controller provides the whole hardware for convenient acceptance filtering and message management. For
each message to be transmitted or received this module contains one so called message object in which all information
regarding the message (e.g. identifier, data bytes etc.) are stored.
During the initialization of the peripheral, the application defines which messages are to be sent and which are to be
received. Only if the CAN controller receives a message whose identifier matches with one of the identifiers of the
programmed (receive) message objects the message is stored and the application is informed by interrupt. Another
advantage is that incoming remote frames can be answered automatically by the full-CAN controller with the corresponding
data frame. In this way, the CPU load is strongly reduced compared to a basic-CAN solution.
Using full-CAN controller, high baudrates and high bus loads with many messages can be handled.
ATmega16/32/64/M1/C1 [DATASHEET]
145
7647O–AVR–01/15
MICROCHIP [ MICROCHIP ]
