# Error detection and handling

10 May

**Error detection and handling: **CAN devices implement multiple error-detection schemes. As previously mentioned, message frames contain a CRC value for verifying the validity of the data received. If a receiver determines an error as a result of examining a frame and its CRC, then it does not acknowledge receipt of the message. If no device acknowledges a message frame, then the transmitter knows that there was an error in transmission. Each transmitter also performs a frame check while transmitting a message. If a transmitter detects a dominant bus state for any of these bits, then the transmitter aborts and generates a frame error:

• CRC delimiter

• Acknowledge delimiter

• End of frame

• Interframe space

Each transmitter also performs bit monitoring except when checking the arbitration field. If it detects the wrong bit on the bus (different from what it was trying to transmit) then it aborts transmission and generates an error frame. After generating an error frame, a CAN device tries to transmit the message frame again.

**Synchronization and bit stuffing**

With CAN, the data transmission is synchronous. Each node has its own internal clock (oscillator) but it needs to synchronize itself with the data on the bus. Each node is hard synchronized at the beginning of each message by the falling edge of the start-of-frame bit. Additionally, each CAN node is resynchronized on each recessive- dominant falling edge in a message. Bit stuffing allows for the CAN devices on a bus to resynchronize with the data in the event that the data being transmitted contains long consecutive runs of the same value. What happens is that a CAN transmitter will detect five consecutive bits of any single value and insert one bit of the opposite polarity. The CAN receiver will do the opposite; whenever it sees five consecutive bits of the same value it will remove the next bit from the message frame. Bit stuffing ensures that there are enough recessive-dominant falling edges in the data stream to keep the other nodes on the bus in synchronization.

**Bit timing**

The bit rate of data transmission on the CAN bus is the number of bits per second that are transmitted. The nominal bit time is the time required to put one bit on the bus (1/bit rate). A CAN controller can have this bit time programmed to various times for different bitrates. The CAN specification partitions this bit time into four time segments. Each of these time segments is an integer number of time quanta long (the exact number varies depending on the bitrate). A time quantum is a unit of time that is derived from the transmitter clock frequency (the CAN controller CPU oscillator). A time quantum is some fraction of the transmitter clock as determined by a bit rate prescaler. Each bit has a minimum of eight time quanta and a maximum of 25. The four segments of a bit time are shown below:

Figure 12-10: Bit time

• Synchronization Segment – This is the time required to synchronize each node to the bus. This segment is always 1 time quantum.

• Propagation Segment – This is the part of a bit that is used to compensate for the physical delay on the network. This segment can vary from 1 to 8 time quanta.

• Phase Buffer Segment 1 – This is used to compensate for edge phase errors before the sample point. This part of the bit time can vary from 1 to 8 time quanta.

• Phase Buffer Segment 2 – This is used to compensate for edge phase errors after the sample point. This part of the bit time can vary from 1 to 8 time quanta. Phase Buffer Segment 2 is less than or equal to Phase Buffer Segment 1.

The sample point between the phase buffer segments is the point in time when the CAN node samples the bus and interprets the value of that particular bit.

The bit time and therefore the bit rate is determined by programming the width of the time quantum and the number of time quanta in the various segments.

It may be necessary to resynchronize the CAN receiver clock based on a recessive to dominant falling edge. To do this, the phase buffer segment 1 may be lengthened or the phase buffer segment 2 may be shortened. The amount of shortening or lengthening is called the resynchronization jump width and is programmable and must be greater than 0 and less than or equal to the smaller of either 4 time quanta or Phase Buffer Segment 1.

All of this gets a bit confusing, so perhaps an example will help. Actually, we need an example as we will need to figure out these segment values when programming TINI. We will use some information specific to TINI and we will revisit this topic again when we start programming. The TINI microcontroller has an 18.432-MHz clock. This is the clock that the CAN controller that is built into the Dallas Semiconductor’s 80C360 CPU uses. Let’s assume we are interested in transmitting data on the CAN bus at 125,000 bits/second. How long is a time quantum and how many time quanta would we need to program the various segments to?

First we find the desired bit rate:

bit time = 1/bit rate = 1/125000 bps (bits per second) = 8 µs (microseconds)

Then we find the clock time of the CPU:

clock time = 1/clock frequency = 1/18.432 MHz = 0.05425 µs

Since the time quantum is an integer multiple of the clock time, we need to find some bit rate prescaler to give us a reasonable value. We could pick a time quantum equal to the clock time but we would need 147 time quanta to make up a bit and that wouldn’t do at all since a bit time has a maximum of 25 time quanta. The idea in picking a reasonable bit rate prescaler is in finding one that results in a bit time that is between 8 and 25 time quanta in length. Let’s pick 7 (I know that will work, but you can try others if you like).

bit rate prescaler = 7

Then we compute a time quantum:

time quantum = bit rate prescaler / clock = 7 / 18.432 MHz = 0.379 µs

Once we have a time quantum, we need to figure out how many of them are needed to make a bit time:

N time quanta = bit time / time quanta = 8 µs / 0.379 µs = 21.108

But since we need to use integer multiples of time quanta, we will need 21 time quanta to make a bit. That is good as it is ≥ 8 and ≤ 25 and that’s what we need. Now we allocate these 21 time quanta using the requirements of the bit time:

Synchronization is always 1 time quantum.

Propagation Segment can vary from 1 to 8 time quanta.

Phase Buffer Segment 1 can vary from 1 to 8 time quanta.

Phase Buffer Segment 2 can vary from 1 to 8 time quanta and is < Phase Buffer

Segment 1.

Let’s pick these, although there are a number of possibilities that all add up to 21 that will work:

Synchronization = 1

Propagation Segment = 5

Phase Buffer Segment 1 = 8

Phase Buffer Segment 2 = 7

The exact allocation of time quanta to the various segments may vary a bit. In reality, on TINI the Synchronization, Propagation Segment and Phase Buffer Segment 1 are treated as a single unit that can vary from 2 to 16.

All that’s left is to pick a synchronization jump width. This is not calculated, just picked; 1 or 2 is a good number. It needs to be ≥ 1 and ≤ the smaller of (4, Phase Buffer Segment 1).

So, how good are these numbers? Let’s find the error.

Actual bit time = 21 time quanta x 0.379 µs = 7.959 µs (we needed 8 µs)

Actual bit rate = 1 / Actual bit time = 1/ 7.959 µs = 125,644 bits/second.

Bit rate error = (Actual Bit Rate – Desired Bit Rate) / Desired Bit Rate

= (125644 – 125000)/125000 = 0.5%

OK, 0.5% error, not bad. Actually that’s the limit as the CAN specification lists that this needs to be within 0.5% tolerance.

You can work through other transmission speeds using a similar methodology. Note that with some clock speeds you cannot get less than 0.5% error so you will need to use some other speed or use a different clock. This is the case with TINI. With its 18.432-MHz clock, you cannot get 1-Mbit CAN communication. The Bosch document “The Configuration of the CAN Bit Timing”2 may also prove to be helpful.