CAN

By Virag
 CAN Frames
1. Data Frame
• Start of frame (SOF)
• Arbitration Field
• Control Field
• Data field
• CRC field
• Acknowledgement field (ACK)
• End of frame (EOF)
Start of Frame (SOF)
• The Start of Frame (SOF) in CAN is always a dominant bit (0).

Bus Synchronization:

• The dominant SOF bit marks the beginning of a message, allowing all nodes on the CAN bus to recognize that a new

frame is starting.

• It ensures that all nodes synchronize to the start of the message and can prepare to participate in the arbitration

process.

Collision Avoidance:

• Since a dominant bit (0) overwrites a recessive bit (1) on the bus, it ensures that any node transmitting a frame will

immediately take control of the bus.

• If multiple nodes attempt to send at the same time, the arbitration process begins after the SOF, ensuring only one

message is transmitted.
 Arbitration Field
• Standard format (11 bits identifier) – 2^11 different message ID’s
• 11 bits identifier
• Remote transmission request (RTR)
• For data frame it is dominant bit (0) and for remote frame it is (1)
• In case both data frame and remote frame are sent on the bus at the same time, data frame will win arbitration
because of dominant bit.
• Extended Format (29 bits identifier) – 2^29 different message ID’s
• 11 bit-based ID
• SRR - Substitute Remote Request – Always Recessive
• The SRR bit is located in the same position as the Remote Transmission Request (RTR) bit in the standard frame.
RTR bit of standard frame will be dominant while the SRR bit of the extended frame is recessive.
• By making the SRR bit always recessive, standard frames have higher priority over extended frames during
arbitration if both frames have the same 11-bit identifier. This preserves backward compatibility and ensures that
extended frames do not block or interfere with standard frames on the CAN bus.
• IDE – Identifier Extension - This bit indicates whether the frame is standard (IDE = 0) or extended
(IDE = 1).
• 18 bits extended ID
• RTR – Remote Transmission Request
Control Field

• Standard Format
• IDE – Identifier Extension - This bit indicates whether the frame is standard
(IDE = 0) or extended (IDE = 1).
• r0 – This bit is not used, reserved for future extensions. Always Recessive
• DLC – Data Length Code (4 bits) indicates no. of data bytes in Data field. May
take values from 0 to 8 (no. of data bytes), other values are not allowed.
• Extended Format
• r1 - This bit is not used, reserved for future extensions. Always Recessive
• r0 - This bit is not used, reserved for future extensions. Always Recessive
• DLC - Data Length Code (4 bits) indicates no. of data bytes in Data field. May
take values from 0 to 8 (no. of data bytes), other values are not allowed.
 Data Field (0 to 8 bytes (0 to 64 bits))
The Data Field in a CAN frame contains the actual payload or
data being transmitted.
• The data field can contain between 0 to 8 bytes (0 to 64 bits).
•The exact number of data bytes is specified by the Data Length Code (DLC) in the control field.
•The data field holds the information that the transmitting node wants to send, such as sensor readings,
commands, or any type of information relevant to the application.
•In remote frames, the data field is absent because the remote frame is used to request data from another
node, not to send data.
• 0byte data –
•used to send a command or signal without needing any additional data.
•It could be a simple control signal like "start" or "stop," where no actual data is required, just the identifier itself to convey
meaning.
•1byte data –
•This is used when only a small amount of information is needed, such as a status update, a control command, or a small
sensor reading (e.g., temperature or pressure value).
•8byte data –
•multiple sensor values, complex control commands, or bulk data like configuration parameters.
• Transmission start with the 1 st
data byte (byte0), MSB 1st.
CRC Field
• CRC Sequence
• Contains 16 bits cyclic redundancy code (CRC).
• CRC is complex but fast and efficient error detection method.
• It helps verify that the data received is the same as the data sent.
•It contains the Cyclic Redundancy Check value, which is computed by the sender based on the frame's contents

(excluding the CRC field and ACK field).

•The receiver uses the same algorithm to recalculate the CRC and compares it to the received CRC value to detect

transmission errors.

•CRC is calculated using a polynomial division method.

• Delimiter
• Marks the end of the CRC field
• allows for CRC processing time.
• Always Recessive
Steps to calculate the CRC
• The CRC is calculated over the bits of the CAN frame, starting from the Start of Frame up
to the Control Field. This includes the identifier, control field, and data field (if present).
• The CAN protocol uses a fixed polynomial for CRC calculations:
•Standard CAN (11-bit identifier) uses the polynomial:
x^15 + x^14 + x^10 + x^8 + x^7 + x^4 + x^3 + 1
• This polynomial is predefined and is used by both the sender and receiver to compute the
CRC value.

CRC Calculation Remaining - Learn Bitwise Division, Hamming Distance and related
concepts
Acknowledgement Field
The acknowledgment field serves as a confirmation of a successful CRC (checksum) check by the
receiving nodes in the network.

• ACK Slot
• During the ACK slot, the message transmitting node switches to receive mode by sending a recessive
signal to the bus. At the same time, all other nodes in the network accomplish their individual CRC
(checksum) check (according to the CAN standard, all nodes must determine the checksum in the same
standardized way) and output a dominant signal to the bus when the check was successful.
• The message transmitting node monitors the bus and expects a dominant level during the ACK slot. This will be the case
when either one of the receiving CAN Bus nodes outputs a dominant level.
• If all nodes in the network determine a checksum error, meaning the sending node monitors a recessive level in the ACK
slot, it is clear that the sending node calculated a wrong checksum. The error is therefore local at the sending node.
• Any receiving node detecting a checksum error will post an error frame to the bus, i.e., right after the completed
acknowledgment field. With this scenario, it is possible to determine whether or not the actual malfunction is with that
particular receiving node.
• The ACK slot may remain dominant, while at the same time, an error is reported by only one receiving node, meaning this
single node will send out an error frame. The error is therefore local at that particular receiving node.
• The CAN standard allows the so-called “self-retirement” (or self-removal) of nodes from the network due to an excessive
number of transmit or receive errors (see Error Detection and Fault Confinement).
• ACK Delimiter
• Once the data is received, the receiving end sends an acknowledgement to the transmitting
node, and it requires some time, and hence ACK delimiter is used.
• The ACK Delimiter Bit is always recessive. This is necessary to distinguish a successful acknowledgment from an
occurring error frame. An error frame starts with at least six successive dominant bits, meaning the first bit of an error
End-of-Frame Field (7 bits, recessive)

• Each data or remote frame is terminated by a bit sequence of 7

recessive bits.
• Each CAN message frame, regardless of the message ID length, will
be terminated by a sequence of 11 recessive bits: The ACK Delimiter
bit in the Acknowledgement Field (1 bit), the End of Frame Field (7
bits), and the Intermission Field (3 bits).
• More specifically: With the combination of the EOF Field and the
preceding recessive ACK Delimiter Bit, each message (data and
remote) frame is terminated by eight recessive bits plus, unless an
overload frame occurs, the three recessive bits of the Intermission
Field.
Interframe Space (IFS) (3 Bits, Recessive)
• The Interframe Space represents the minimum space between frames of
any type (data, remote, error, overload) and the following data or remote
frame.
• During the Interframe Space (intermission), no node can start transmitting
a data or remote frame. Only the signaling of an overload condition is
allowed.
• There is no Interframe space between error and overload frames.
• The Interframe Space can not necessarily be considered to be a part of a
data or remote frame; however, in a well-functioning CAN network, it will
always follow behind a data or remote frame.
• IFS is needed by controllers to copy received frames from their Rx buffers.
2. Remote Frame
• Used to request a transmission of specific data frame.
• Similar to Data Frame, but data field is absent.
• Remote Transmission Request (RTR) bit is recessive.
• Same identifier as the Data Frame which is requested.
CAN Errors

Exceptions: During Arbitration and

Acknowledgement
Bit Stuffing Error
• As explained, bit stuffing is part of the CAN standard. It
dictates that after every 5 consecutive bits of the same
logical level, the 6th bit must be a complement. This is
required to ensure the on-going synchronization of the
network by providing rising edges. Further, it ensures that a
stream of bits are not mis-interpreted as an error frame or as
the EOF (7bit recessive sequence) that marks the end of a
message. All CAN nodes automatically remove the extra bits.
• If a sequence of 6 bits of the same logical level is observed
on the bus within a CAN message (between the SOF and CRC
field), the receiver detects this as a Bit Stuffing Error aka
Stuff Error.
Intro to CAN errors handling
• https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial