Bus Errors

Obtaining Bus Status Information

Use canReadErrorCounters() to read the error counters of the CAN controller. There are two such counters in a CAN controller (they are required by the protocol definition).

Note
Not all CAN controllers allow access to the error counters, so CANlib may provide you with an "educated guess" instead.

Use canReadStatus() to obtain the bus status (error active, error passive, bus off; as defined by the CAN standard).

Overruns

If the CAN interface or the driver runs out of buffer space, or if the bus load is so high that the CAN controller can't keep up with the traffic, an overload condition is flagged to the application.

The driver will set the canMSGERR_HW_OVERRUN and/or canMSGERR_SW_OVERRUN flags in the flag argument of canRead and its relatives. The flag(s) will be set in the first message read from the driver after the overrun or overload condition happened.

Not all hardware platforms can detect the difference between hardware overruns and software overruns, so your application should test for both conditions. You can use the symbol canMSGERR_OVERRUN for this purpose.

Error Frames

When a CAN controller detects an error, it transmits an error frame. This is a special CAN message that causes all other CAN controllers on the bus to notice that an error has occurred.

CANlib will report error frames to the application just like it reports any other CAN message, but the canMSG_ERROR_FRAME flag will be set in the flags parameter when e.g. canRead() returns.

When an error frame is received, its identifier, DLC and data bytes will be undefined. You should test if a message is an error frame before checking its identifier, DLC or data bytes.

In an healthy CAN system, error frames should rarely, if ever, occur. Error frames usually mean there is some type of serious problem in the system, such as a bad connector, a bad cable, bus termination missing or faulty, or another node transmitting at wrong bit rate, and so on.

SJA1000 Error Codes

Many of our CAN interface boards use the SJA1000 CAN controller. When an error occurs on the bus, the device firmware and driver will pass the error code from the CAN controller to the application by using the CAN identifier field. The identifier will be set to 0x800 (2048) plus the error code from the controller. The flag field will contain the canMSG_ERROR_FRAME flag. The data length will be 0.

You can use the following tables to interpret the error code from the controller. Note that they are applicable only to those CAN interfaces that use SJA1000.

Bit 7Bit 6Meaning
00bit error
01form error
10stuff error
11other type of error



Bit 5Meaning
0TX; error occurred during transmission
1RX; error occurred during reception



Bit 4..0Meaning
0x03start of frame
0x02ID.28 to ID.21
0x06ID.20 to ID.18
0x04bit SRTR
0x05bit IDE
0x07ID.17 to ID.13
0x0FID.12 to ID.5
0x0EID.4 to ID.0
0x0Cbit RTR
0x0Dreserved bit 1
0x09reserved bit 0
0x0Bdata length code
0x0Adata field
0x08CRC sequence
0x18CRC delimiter
0x19acknowledge slot
0x1Backnowledge delimiter
0x1Aend of frame
0x12intermission
0x11active error flag
0x16passive error flag
0x13tolerate dominant bits
0x17error delimiter
0x1Coverload flag

Example
A message is transmitted on the CAN bus. A stream of error frames are returned. canRead() reads messages with id 0x000008D9, dlc = 0 and flags = 0x20 (canMSG_ERROR_FRAME). What's up?

Using the tables above, we see that 0xD9 means

  • Other type of error.
  • Error during transmit.
  • Acknowledge slot.

so it is likely that the module transmitting the message doesn't get any answer.

Note
We make no guarantee that this feature will be present in future releases of hardware, drivers and firmware.
We recommend that you use this feature for troubleshooting a particular installation only. Do not write your software so it relies on this feature.