---
title: "CAN bus"
date: 2012-10-22
---

I've started working with [CAN bus][1] for a new project I'm doing, using
[Microchip's MCP2515 CAN controller][2] and [MCP2551 CAN transceiver][3]. In
this blog post I'll explain how the CAN bus works at the bit level, to make it
easier for us to debug when something isn't working.

imagethumb:breadboard.jpg[CAN bus on a breadboard]

I hooked up a quick circuit using an ATmega32 and the two CAN bus chips. I used
SPI to send a single CAN data frame to the target ID 0x555, and then captured
the frame using a logic analyzer.

imagethumb:frame.png[CAN bus frame format]

## Working Backwards
Let's pick through our message and understand where each of the bits came from.
The bit stream that we captured with the logic analyzer was

field: abbbbbbbbbbbcccdddddeeeeeeeeeeeeeeefgghhhhhhh
bits:  010101010101000001001100111010011001011111111

which corresponds to the [Start of Frame marker]{.a}, [Arbitration Field]{.b},
[Control Field]{.c} (including [Data Length Code]{.d}), [CRC sequence]{.e}
(including [CRC delimiter]{.f}), [ACK field]{.g}, and [End Of Frame (EOF)
delimiter]{.h}. Note that the [Control Field]{.c} contains a run of five **0**
bits, which means a **1** bit has been stuffed into the value. So we know that
we should remove that extra 1 bit from the [Data Length Code]{.d} to get the
correct value of [0000]{.d}. So this message has a payload of 0 bytes. The
"Arbitration Field" is just another name for the "Identifier", and our
extracted identifier is **10101010101** or **0x555**.

The first three bits of the [Control Field]{.c} are the RTR bit,
IDE bit, and **r0** reserved bit. In our message these three bits are all 0. The
RTR bit represents whether this CAN frame is a Remote Transmission Request or
not. Apart from error handling, every CAN frame is either a Remote Frame (the
sender is requesting some kind of reply from the receiving node), or is a data
frame. The IDE (ID Extension) bit represents whether this data frame is
addressed to an extended ID (an extended CAN message). Some manufacturers
decided that 11 bits couldn't address all of their devices (211 = 2048). So
they took an unused bit from the old CAN bus Control Field and called it the
IDE bit. When the IDE bit is set, the message structure is slightly longer, and
there is an additional 18-bit Identifier field meaning that an extended CAN
message can address up to 229 = 536870912 different devices on the same bus
(wow!). Alternatively, these ID bits can be split up among several fields
(priority, category, sender type, etc). For now we'll ignore extended IDs,
because we sent ourselves a standard CAN bus data frame (IDE bit = 0).

Since our [Data Length]{.d} is **0**, we have 0 bytes of payload.  So the next
field is the [CRC sequence]{.e}, and the [CRC delimiter]{.f}. To understand
where the CRC sequence came from, we need to understand a little bit about [CRC
checksums][4]. I will assume that you've read up on how CRC works. The
polynomial that CAN bus uses for the CRC calculation is $x^15 + x^14 + x^10 +
x^8 + x^7 + x^4 + x^3 + x^0$ (according to the official documentation). We then
checksum all the bits from the [Start of Frame Marker]{.a} until just before
the [CRC sequence]{.e}, except for any stuffed bits that have been inserted to
break up long runs of the same bit value. So after we remove the stuffed bit
that was inserted into the Data Length field, we get the bit sequence
**0101010101010000000**, or **0x2AA80**. We can use an online tool to help us
perform the CRC calculation, and we will find that the generated value is
[**0b110011101001100**]{.e}, which is the same value that was contained in the
original CAN frame. The [CRC delimiter]{.f} is always 1 (recessive state).

The first bit of the [ACK field]{.g} (the ACK bit) is transmitted as 1
(recessive state) by the sender of a data frame, and anyone who has heard the
message and verified its CRC checksum pulls the bus into a dominant state (0
bit) during the message's ACK bit, which tells the sender that at least one
receiver has successfully read the message. Note that we can't tell how many
other nodes successfully received the message -- we can only tell if **nobody**
received it, or **at least one node** got it. Most CAN controllers are
configured to repeat a message until it gets received by someone. The second
bit of the ACK field is always 1 (recessive).

Finally, the [End Of Frame (EOF) delimiter]{.h} marks the end of a CAN frame
with 7 recessive bits.

That wasn't so bad!

[1]: http://en.wikipedia.org/wiki/CAN_bus
[2]: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010406
[3]: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405
[4]: http://en.wikipedia.org/wiki/Cyclic_redundancy_check

UPDATE: I've added a bit of code to perform the CANbus CRC calculation below:

```
#include <stdio.h>
#include <stdint.h>
 
uint16_t can_crc_next(uint16_t crc, uint8_t data)
{
    uint8_t i, j;
 
    crc ^= (uint16_t)data << 7;
 
    for (i = 0; i < 8; i++) {
        crc <<= 1;
        if (crc & 0x8000) {
            crc ^= 0xc599;
        }
    }
 
    return crc & 0x7fff;
}
 
int main()
{
    int i;
    uint8_t data[] = {0x02, 0xAA, 0x80};
    uint16_t crc;
 
    crc = 0;
 
    for (i = 0; i < sizeof(data); i++) {
        crc = can_crc_next(crc, data[i]);
    }
 
    printf("%x\n", crc);
}
```

<style>
.a,.b,.c,.d,.e,.f,.g,.h { font-weight: bold; font-family:monospace; }
.a {color: red}
.b {color: mediumblue}
.c {color: green}
.e {color: deepskyblue}
.g {color: orange}
.d {color: purple}
.f {color: magenta}
.h {color: limegreen}
</style>