Why is the CAN bus always busy (microcontroller)?

Question

I'm trying without success to perform CAN bus communication between an microcontroller and the host (my computer). My question does not depend on the microcontroller, but on the CAN Bus (classic CAN).

My application tries to send a frame each (5 ms, 10 ms, 100 ms). I have a simple scheduler that execute tasks where I call the function can_write(HwObject,Frame) to write the frame to the bus.

However, the first frame returns OK and it's received at the host, but after that (and for all the following frames) the function returns busy, and I keep seeing the error counter increasing without any frame arriving at the host. Finally the node seems to go into bus off mode.

I want to know what are the main reasons for that: I'm using the same baudrate, 1 Mbit/s, on both sides, but I also tried different ones, but without success to see any results. I have looked around registers to see what could be the issue. For example I get:

1. The bus detects a transmit abort request.
2. The channel enters to halt mode after bus off.
3. The bus is in passive mode.
4. A channel bus error is detected.
5. Error warning is detected.
6. Overload is detected.
7. A bit stuff error is detected.

PSS: I'm following the AUTOSAR Standard: The CAN specification can be found at: https://www.scribd.com/document/160011317/Autosar-Sws-Candriver

But I can't find what causes this issue. I think it is due to bad synchronization!

Answer 1

There are usually two causes of this:

1. The bus terminators are not installed. The 120 Ω terminators at each end of the bus perform two functions:

   1. Absorb the energy that would otherwise be reflected by the open end of the cable. This is particularly important on long busses and at high bit rates.

   2. To keep the bus in the recessive state when it is not driven. You can think of CAN as being like a open collector line, except that it is implemented as a differential signal. On a open collector line, there needs to be a pullup to keep the bus high when it is not driven. On CAN, you instead need pull-together resistors. They keep the bus in the recessive state when not driven.

2. No other unit on the bus is receiving the message. This means nobody is sending the ACK required at the low protocol level. When you only have two nodes on the bus, then both have to be up and running for the bus to work. It's not like RS-232, for example, where one node can send and it doesn't matter whether anyone else is listening.

   When the sender receives no ACK, it retries continually. Eventually it may go off line after too many retries, depending on how the error handling and recovery is set up.

   If the bus is intact and signals are correct, then this is a firmware problem with the second node.

As with any debugging, you do tests that tell you which part of the system the problem in not in. The obvious thing to do here is to look at the CAN signals and see if they are right. Remember that CAN is a differential signal. The single signal value that bus nodes interpret is (CAN+)-(CAN-). That should be essentially 0 in recessive state and about 1.8 V in the dominant state. Most bus driver chips, like the common MCP2551, will use about 2.5 V common mode voltage.