145
Atmel ATmega16/32/64/M1/C1 [DATASHEET]
7647K–AVR–12/13
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.