I ran some CAN example code on my Arduino setup, and it worked as expected. Now I'm trying to understand the CAN protocol in depth instead of just using the example code.

I've written down my understanding of how I think it works. I'm fairly confident in my reasoning, but I'd really appreciate a second opinion from someone with more experience working with CAN. Even if my understanding is mostly correct, an experienced person @Papabravo might catch something I've overlooked.

CAN is a communication protocol mainly used in the automotive industry and industrial automation. It uses two communication lines, CAN High (CAN_H) and CAN Low (CAN_L). It works using a differential signalling mechanism, which makes communication more reliable in noisy environments.

On the CAN bus, we have two logic states:

• Dominant bit (0)
• Recessive bit (1)

When a sender node wants to transmit a dominant bit (0), it drives CAN High to about 3.5 V and CAN Low to about 1.5 V. The receiver measures the voltage difference between the two lines (about 2 V) and recognizes it as a dominant bit.

When the sender wants to transmit a recessive bit (1), both CAN High and CAN Low remain at approximately 2.5 V, so the differential voltage is almost 0 V. The receiver recognizes this as a recessive bit.

One important property of the CAN bus is that any node can force a dominant bit onto the bus, but no node can force a recessive bit if another node is transmitting a dominant bit.

CAN is a message-based protocol, which means messages are identified by their identifier (Message ID) instead of the destination node address. Any node can transmit a message, and every node receives it. Each receiver decides whether to accept or ignore the message using its acceptance filters and masks.

Whenever a node wants to transmit a message, it must follow the CAN frame format.

A CAN data frame contains the following fields:

• Start of Frame (SOF)
• Arbitration Field
• Control Field
• Data Field
• CRC Field
• ACK Field
• End of Frame (EOF)

Normally, when no node is transmitting, the CAN bus remains in the recessive state, with both CAN High and CAN Low at approximately 2.5 V.

To begin communication, the transmitting node sends the Start of Frame, which is one dominant bit. Therefore, the bus changes from recessive to dominant, indicating that a new message is starting.

The next field is the Arbitration Field, which contains the Message Identifier and the RTR (Remote Transmission Request) bit. This field is used for bus arbitration.

If more than one node starts transmitting at the same time, they all transmit their identifier while simultaneously monitoring the bus. Since dominant (0) always overrides recessive (1), the message with the lowest numerical identifier (highest priority) wins arbitration.

For example, suppose two nodes transmit the following identifier bits

Node A : 10011...

Node B : 10010...

Both nodes transmit the same bits until the last bit shown. At that point, Node A transmits 1 (recessive) while Node B transmits 0 (dominant). Since the bus becomes dominant, Node A realizes that the bus does not match what it transmitted, so it immediately stops transmitting and becomes a receiver. Node B continues sending the rest of the message without interruption.

This arbitration process only occurs during the Arbitration Field.

The next field is the Control Field. One important bit is the IDE (Identifier Extension) bit, which indicates whether the frame uses the Standard 11-bit identifier or the Extended 29-bit identifier. The Control Field also contains the DLC (Data Length Code), which specifies how many data bytes are present in the Data Field. In Classical CAN, the DLC can indicate 0 to 8 data bytes. For example, if the DLC is 2, then the message contains two bytes of data.

Next comes the Data Field, which contains the actual information being transmitted.

After that is the CRC Field. The sender calculates a 15-bit CRC from the transmitted message and appends it to the frame. The receiver performs the same CRC calculation on the received bits and compares the result with the received CRC value. If they do not match, the receiver detects a CRC error, indicating that the message was corrupted during transmission. After the 15 CRC bits, there is a CRC Delimiter, which is one recessive bit. It simply marks the end of the CRC Field

The next field is the ACK (Acknowledgement) Field, which is used to indicate that the message was received correctly. The transmitter sends a recessive bit in the ACK Slot. If at least one receiver successfully receives the frame without detecting any errors, it overwrites that bit with a dominant bit. The transmitter monitors the ACK Slot, and if it reads a dominant bit, it knows that at least one node received the message correctly. It does not know which node acknowledged it. The next bit is the ACK Delimiter and It simply marks the end of the ACK Field and separates it

Finally, the transmitter sends the End of Frame (EOF), which consists of 7 recessive bits, indicating that the frame has finished and the bus returns to the idle (recessive) state.

Sorry for the too long post. I have a few doubts about some parts of the CAN protocol, but before moving on to those, I wanted to make sure my understanding of the frame format is correct

 

Your summary is correct, although it is not as good as RS485 for noise immunity because the bus relies on termination resistors to return it to the recessive state. The dominant/recessive is, however, essential to the operation of CAN as it allows it to deal with data collisions in hardware. If one node tries to send recessive at the same point another sends dominant, each node reads back what the bus is doing, and if there is a disagreement, the node trying to send recessive abandons its attempt, but automatically retires as soon as the bus is idle.
Unlike various RS485 protocols, where the software has to keep track of who is sending and who is receiving, CAN has the hardware deal with it, so there is no processor overhead. Just set up the message, tigger it to send, and the hardware ensures it is delivered. Thus, if you can set up the peripherals, you don’t actually need to know precisely what is going on.

 

You omitted the topic of Bit stuffing. https://medium.com/@sjindhirapooja/bit-stuffing-in-can-8c13de61b613

 

Your summary is correct,

One thing I'm still confused about is where arbitration effectively ends.

I'm thinking about a very rare scenario where two nodes start transmitting at exactly the same time and have the same message ID. If they also happen to have the same control field and identical data bytes, then they would generate the same 15-bit CRC sequence as well (excluding the CRC delimiter).

I know this is an extremely unlikely situation in a real system, but theoretically, could both nodes continue transmitting together all the way through the CRC sequence without either one losing arbitration? Or does arbitration actually end of data filed?

I'm asking because I'm trying to understand how the protocol behaves in this cases, not because I expect this to happen in practice.

 

You omitted the topic of Bit stuffing. https://medium.com/@sjindhirapooja/bit-stuffing-in-can-8c13de61b613

My understanding of bit stuffing is this

When the transmitter detects five consecutive bits of the same polarity (for example, 11111 or 00000), it automatically inserts a stuff bit of the opposite polarity. So after 11111, it transmits a 0, and after 00000, it transmits a 1.

The receiver performs the same check while receiving the frame. If it sees five identical bits followed by the expected opposite-polarity stuff bit (for example, 111110), it removes the stuff bit and continues processing the frame normally.

However, if the receiver sees six consecutive identical bits instead (for example, 111111), it knows that the required stuff bit was missing or corrupted, so it detects a bit stuffing error and treats the frame as invalid.

 

One thing I'm still confused about is where arbitration effectively ends.

I'm thinking about a very rare scenario where two nodes start transmitting at exactly the same time and have the same message ID. If they also happen to have the same control field and identical data bytes, then they would generate the same 15-bit CRC sequence as well (excluding the CRC delimiter).

I know this is an extremely unlikely situation in a real system, but theoretically, could both nodes continue transmitting together all the way through the CRC sequence without either one losing arbitration? Or does arbitration actually end of data filed?

I'm asking because I'm trying to understand how the protocol behaves in this cases, not because I expect this to happen in practice.

They really shouldn’t have the same message ID. They will continue to transmit in parallel until the messages differ. At that point the one trying to send recessive loses and gives up, and the dominant wins. If the entire ID and number of bytes were all identicAl, the one sending the numerically lowest data wins.

 

You wrote:
CAN is a message-based protocol, which means messages are identified by their identifier (Message ID) instead of the destination node address. Any node can transmit a message, and every node receives it. Each receiver decides whether to accept or ignore the message using its acceptance filters and masks.

It is true that any node can transmit a message, but multiple nodes should NOT transmit messages with identical arbitration fields since that would defeat the whole purpose of arbitration. Arbitration continues for the entire length of the arbitration field, which may include the Data Length Code, and if the network rule is that two nodes may NOT have the same identifier is enforced by design, then arbitration will end at the end of the identifier field.

At, Allen-Bradley in the Device-Net implementation we had a MAC address embedded in the 11-bit identifier field and a power on node protocol to detect duplicate MAC addresses on an active network. Having this higher-level protocol on top of CAN. made network commissioning and debugging ever so much easier. It was often the case that nodes which went Bus-Off were victims rather than perpetrators.

 

I made a list of the topics I think are important:

• Arbitration
• Framing
• Synchronization
• Acknowledgements
• Error detection
• Retransmission
• Fault confinement

At the moment, I think I have a good understanding of the frame format, so I don't have questions about framing.

My main confusion is synchronization.

For example, if all nodes are configured for a 500 kbps baud rate, and a transmitter wants to send a frame, it starts with the dominant Start of Frame (SOF) bit. All other nodes detect that dominant edge and know that a transmission has started.

What I'm trying to understand in more detail is the timing after that. There must be a defined point at which the transmitter changes to the next bit, and there must also be a defined point at which the receivers sample the current bit. I assume each bit has a period during which the signal is stable before the receivers sample it, but I don't yet understand exactly how CAN defines these timing points and keeps all nodes synchronized throughout the frame.

Another topic I'm not completely clear on is bit error detection.

I understand that a bit error occurs when a transmitting node sends one bit but reads back a different bit on the CAN bus. I see that CAN uses a wired-AND bus with open-drain/open-collector style outputs

What I don't fully understand is how the transmitting node actually reads back what is present on the bus. Is there some kind of internal feedback path in node while transmitting? I understand the wired-AND logic conceptually, but I'm missing the hardware-level picture of how the transmitter compares the bit it intended to send with the actual bus state.

As for retransmission, I think I understand the basic idea. If a frame is interrupted by an error, whether it's a bit error, CRC error, ACK error, bit stuffing error, or another transmission error, the current frame is aborted, an error frame is generated, and the original transmitter automatically retries sending the message once the bus becomes idle again. So I don't think I have any major confusion about the retransmission mechanism itself.

Regarding fault confinement, My understanding is that if a node repeatedly transmitting faulty frames, CAN protocol doesn't allow it to continue after some limits. when the transmit error counter reaches 256, the node enters the Bus Off state and is no longer allowed to transmit on the bus

Those are the parts I'm currently trying to understand in more detail, and I'd really appreciate any corrections or explanations

 

There is a setting somewhere in the configuration word which tells it to sample at 7/8th of a bit time after the edge. I think there’s a phase-locked-loop that keeps track of that point if there a lot of identical bits together. The bit stuffing is to keep that PLL on track. The the transmitter changes to the next bit 2us after it started the first bit. It does so based solely on the baud rate timer.
Error detection is done by the CRC at the end of the transmission. The receiver sets a flag to say that the CRC agrees or disagrees when new data arrives.
Acknowledge is done by any receiving node, which puts a dominant bit in the slot which is normally recessive. If there’s no acknowledge the transmitter keeps retransmitting until it gets one.
Note that ANY node can do the acknowledge, it doesn’t necessarily mean that the data got to its destination, it just says that one receiver on the bus found a properly formatted dataframe.

 

...
My main confusion is synchronization.

For example, if all nodes are configured for a 500 kbps baud rate, and a transmitter wants to send a frame, it starts with the dominant Start of Frame (SOF) bit. All other nodes detect that dominant edge and know that a transmission has started.

What I'm trying to understand in more detail is the timing after that. There must be a defined point at which the transmitter changes to the next bit, and there must also be a defined point at which the receivers sample the current bit. I assume each bit has a period during which the signal is stable before the receivers sample it, but I don't yet understand exactly how CAN defines these timing points and keeps all nodes synchronized throughout the frame.
...

Synchronization happens on the leading edge the SOF bit. Each bit cell is defined by the "ticks" of a high frequency clock, typically 12 to 24 times the highest data rate supported by the network. In my designs I have used 16 MHz. and 18 MHz. clocks. The CAN controller defines the bit cell as consisting of multiple parts which define the location of the sample point and the allowable Synchronization Jump Width. Tell me which controller you are using, and I'll look up the actual names of the bit cell segments used by that controller

 

ell me which controller you are using, and I'll look up the actual names of the bit cell segments used by that controller

I'm planning to use the PIC18F66K80, which has the integrated CAN controller. I've attached the datasheet for reference https://ww1.microchip.com/downloads/en/devicedoc/39977c.pdf

 

CAN peripherals are all the same, yet they are all slightly different. The main thing to get right is the configuration word and there are websites which will generate it for you, but I bet if you ask Ai for the configuration word for whatever Pic at 500kbaud you’d get the answer. The configuration word sets the baud rate and the timing points where each bit is sampled.

 

I see from the datasheet that you have 4 segments in a bit. The Synchronization segment is a single TQ long. The other segments are the Propagation segment, Time Segment 1 and Time segment 2. As a starting point I recommend you choose parameters for maximum cable length and closely matched oscillator crystals in each node. To do this you select:

• SJW =1
• TSEG2 =2
• TSEG1 =8
• PROPSEG = 5

The total bit time is:

• SYNC SEG =1
• PROP SEG = 5
• TSEG1 = 8
• TSEG2 = 2

For a total of 16 TQ. The sample point will be at 87.5% of the bit cell. Other combinations of PROP SEG and TSEG1 equaling 13 will also work.

If for some reason you are having problems. You can move the sample point away from the end of the bit cell and increase the SJW but be prepared to restrict the maximum cable length. If you choose to use time bases that are less accurate than quartz crystals and/or oscillators you can expect, make the network more forgiving. If you use other frequencies that provide a different number of Time Quanta per bit than 16, you may have to experiment with these parameters to get those nodes to play nice with each other.

The datasheet is very comprehensive and detailed and even I would need to read it more than once to use it effectively. I notice that it mentions DeviceNet capability. I worked on the development of Device Net while I was at Allen-Bradley and subsequently at Huron Net Works, and I can still answer questions about that particular protocol if necessary.

As a debugging aid I recommend making a single node network using a short piece of cable with a termination resistor across CAN_H & CAN_L that is one-half the characteristic impedance of a longer network, On DeviceNet the cable impedance was 120Ω so we use the nearest 1% value which was 60.4Ω. When you send a CAN frame from this lonely node, it will resend the frame forever because there can be no acknowledgement in ACK slot. Now you have a repetitive event you can examine with a good scope or logic analyzer to verify all your assumptions about bit timing, stuff bit and so forth.

Keep asking questions and I will try to answer them. Good luck with your project

 

I think that for most people, even computer professionals, the CAN bus ought to be a case of "Meddle not in the affairs of wizards". You don't need to know exactly how it works, and it's certainly pretty complicated. But using it (with the commonly available interface chips) is simple, and you can't make it work any better by understanding the magic. Just look at the requirements for controlling the interface (i.e. sending and receiving messages) and you've got what you need.

 

I think that for most people, even computer professionals, the CAN bus ought to be a case of "Meddle not in the affairs of wizards". You don't need to know exactly how it works, and it's certainly pretty complicated. But using it (with the commonly available interface chips) is simple, and you can't make it work any better by understanding the magic. Just look at the requirements for controlling the interface (i.e. sending and receiving messages) and you've got what you need.

As long as every piece of code you write works flawlessly, first time out of the box, this might be good advice. When it's 3 AM and you're on a product demo deadline, that extra time spent studying the minutiae of the system pays enormous dividends. I'm just sayin'.

On top of that it really is not that difficult or opaque. It does take some knowledge and concentration.

 

Once you’ve got it set up, it’s easier than the RS485 protocols, as the hardware just does the job.
Before you‘ve got it set up, it can be a complete nightmare. Allow a couple of days of frustration to get it going, and after that you probably won’t have to give it a second thought.

 

One thing I'm still confused about is where arbitration effectively ends.

I'm thinking about a very rare scenario where two nodes start transmitting at exactly the same time and have the same message ID. If they also happen to have the same control field and identical data bytes, then they would generate the same 15-bit CRC sequence as well (excluding the CRC delimiter).

I know this is an extremely unlikely situation in a real system, but theoretically, could both nodes continue transmitting together all the way through the CRC sequence without either one losing arbitration? Or does arbitration actually end of data filed?

I'm asking because I'm trying to understand how the protocol behaves in this cases, not because I expect this to happen in practice.

https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection

 

Keep asking questions and I will try to answer them.

Thank you, I really appreciate that.

One area where I still don't have complete clarity is what actually happens on the bus after an error is detected. I'm trying to understand the complete sequence of events that takes place on the bus once an error is detected.

For example, if one node is transmitting a frame and another node detects an error, the error could be a bit error, bit stuffing error, CRC error, ACK error, or some other error.

From what I've understood so far, it seems that regardless of the type of error, the detecting node transmits an Error Frame to force all nodes to discard the current frame and abort the transmission.

If that's correct, then how does the original transmitter know what kind of error actually occurred? For example, the receiver might have detected a CRC error, a bit stuffing error, or a form error, but if the response is always just an Error Frame, how does the transmitter know what went wrong? Or does it simply know that some error occurred without knowing the specific reason?

In other words, does the detecting node always transmit the same Error Frame regardless of the error type, or are there different error indications on the bus depending on whether it's a CRC error, ACK error, bit stuffing error, form error, and so on?

 

Thank you, I really appreciate that.

One area where I still don't have complete clarity is what actually happens on the bus after an error is detected. I'm trying to understand the complete sequence of events that takes place on the bus once an error is detected.

For example, if one node is transmitting a frame and another node detects an error, the error could be a bit error, bit stuffing error, CRC error, ACK error, or some other error.

From what I've understood so far, it seems that regardless of the type of error, the detecting node transmits an Error Frame to force all nodes to discard the current frame and abort the transmission.

If that's correct, then how does the original transmitter know what kind of error actually occurred? For example, the receiver might have detected a CRC error, a bit stuffing error, or a form error, but if the response is always just an Error Frame, how does the transmitter know what went wrong? Or does it simply know that some error occurred without knowing the specific reason?

In other words, does the detecting node always transmit the same Error Frame regardless of the error type, or are there different error indications on the bus depending on whether it's a CRC error, ACK error, bit stuffing error, form error, and so on?

The transmitter does not care about the particular error that created the original problem. The response is to generate an immediate ERROR frame and retransmit the busted message after the network settles down. The ERROR frame itself creates a bit stuffing error for every node with an active receiver, because it is six consecutive dominant bits. Every node that receives an ERROR frame will also generate an error frame. After every active node has generated an Error frame the node that detected the original error will retransmit the busted frame and the network will proceed as if the error had never occurred.

What I describe above is the ERROR Active frame. There is also an ERROR passive frame, which is 6 consecutive recessive bits. This frame will only be recognized if there are no other ERROR active frames being transmitted.

 

Once you’ve got it set up, it’s easier than the RS485 protocols, as the hardware just does the job.
Before you‘ve got it set up, it can be a complete nightmare. Allow a couple of days of frustration to get it going, and after that you probably won’t have to give it a second thought.

My experience matches the first part of that but not the second! I use a CAN bus with the MCP2515 chips, and I'm running someone's library on an Arduino. I got it wired per directions, installed some code from the library examples folder, and away it went.

This came after a long period when I was using an RS485 network. It was perfectly reliable, but I spent a lot of programming hours ensuring that it would work properly, with the main issue being the question of when a particular node was authorized to transmit. It's impossible to have a true peer-to-peer system with RS485, where there doesn't have to be any kind of master unit directing events. Whereas with CAN, each processor can act as if it has the right to transmit any time it wants. That's why I say there's magic which you don't need to understand--in fact priority is being sorted out, but you can just let it happen.

Another drawback with RS485 in a party-line application is that every processor has to read every byte, in order to decide whether it's being addressed. That leads to a lot of interrupts! On a CAN network, processors are only interrupted if there's a complete message, and even beyond that, the external hardware can filter incoming messages and only alert the processor if it's something that an individual node needs. The amount of hassle involved in using CAN is comparatively very small.