# Bus Errors

## Obtaining Bus Status Information

Use `read_error_counters` 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). Not all CAN controllers allow access to the error counters, so CANlib may provide you with an “educated guess” instead.

Use `readStatus` 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 `HW_OVERRUN` and/or `SW_OVERRUN` flags in the flag argument of `read` 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 `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 `ERROR_FRAME` flag will be set in the flags parameter when e.g. `read` 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.