Datasheet

CAN: Controller Area Network Lab using ST STM32 Cortex-M processors. www.keil.com

Bus Errors:

Recall we said that all nodes (including the transmitting node) check each CAN frame for errors. If an error is detected, here

is what happens:

1. All the nodes will signify this fact by driving the bus to logical 0 (dominant state) for at least 6 CAN bits.

2. This violates the Bit Stuffing rule (never > than 5 bits the same polarity) so every node sees this as an error.

3. This so called “Error Frame” signals to all nodes a serious error has occurred if they don’t already know it.

4. The transmitting bus abandons the current frame and adds 4 to its 8 bit TEC register. (Transmit Error Counter)

5. IF this TEC equals 0xFF, the transmitting node goes BUS OFF and takes itself off the bus. (TEC normally = 0)

6. IF not, it attempts to retransmit its message which has to go through the priority process again with other messages.

7. All other nodes abandon reading the current frame, and add 4 to their own REC register. (Receive Error Counter)

8. Any nodes that have messages queued up will transmit them now. All others start listening to the bus.

9. Hopefully, this time the message will be broadcast and received error free. Each time a frame is transmitted and/or

received successfully, the corresponding TEC and REC registers are decremented (usually by only 1)

Super TIP: Error Counters ? These are two 8 bit registers in every CAN controller and you can read these with your

software. This is a good idea because it gives some indication of general bus health and stability. In a good CAN network,

TEC and REC will equal 0. If it starts having higher values, something has happened to your network. The usual suspect is

bad hardware. The problem is usually in either the wires, the transceiver chip or the termination resistors.

TIP: Don’t forget that if something happens to the integrity of your twisted pair, such as CAN Lo disconnected; it might still

work but with greatly reduced noise immunity (that is what differential signals do best). If your network is in a very noisy

environment, there might be more transient bus errors. This is very tricky to debug without knowledge of the REC and TEC

contents. Read TEC and REC with your software and report it to your diagnostic routines.

In a general sense, TEC represents a given node’s errors and REC indicates the other nodes’ errors.

Bus Off: As mentioned, if a transmitting node detects it has put too many bad frames on the bus, it will disconnect itself. It

will assume that there is something very wrong with itself. To get back on the bus depends on how you configure the

controller. This can require a controller RESET or a certain number of good frames received. See your controller docs.

BUS Faults:

This is different (sort of) from a bus error. We normally think of a bus fault as something that has happened to the “wires” or

the output transistors of the transceiver chip. Not all bus faults will result in a bus error. A bus error can be thought as the

CAN controllers’ reaction to a bus fault such as noise, a faulty node or other errors.

What happens if one of the twisted pair opens or is shorted out ? CAN has automatic mechanisms for this. Not all

transceiver chips implement all of them. You can usually short CAN Lo to ground (ISO 11898 says you can short Hi also) or

open one CAN line. The ground needs to be connected for this case. You can’t short both Hi and Lo together (Fault Tolerant

will work) or open both up. You can cut the ground or have a large ground loop present and CAN will still work.

Serious bus faults may be reported as a bus error as described above. At least one node must try to transmit a frame in a bus

fault condition to trigger a bus error. A bus in idle mode can’t trigger a bus error. When the bus fault is removed, in many

systems the network will come back to life if so configured. CAN has excellent noise immunity because of the twisted pair

that are 180 degrees out of phase. The common mode noise is cancelled out and the differential CAN signal is not affected.

The Ground: Strictly speaking, the ground is not needed for CAN operation if the twisted pair is intact. This is readily

shown with simple experiments. One experiment showed a small network still worked properly with two nodes having a 40

volts DC ground difference ! However, it is a good idea to include a good ground in your system design. Some bus faults

need the ground to allow the transceiver to compensate. This is good engineering practice. Watch out for ground loops !

For a practical demonstration of BUS faults: see the section on getting a real system working.

TIP: How can you create a Bus Error for testing ? Easy: have a node send a message at the wrong frequency. When this

frame tries to get on the bus this is certain to create a bus error condition. Some CAN controllers can send a one-shot frame.

This is useful if the ACK bit does not get set by other nodes and you do not want this frame being sent forever.