Why is the CAN bus always busy (microcontroller)?
There are usually two causes of this:

The bus terminators are not installed.  The 120 &Omega; terminators at each end of the bus perform two functions:

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.

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.



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.