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).
Use canReadStatus() to obtain the bus status (error active, error passive, bus off; as defined by the CAN standard).
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.
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.
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 7 | Bit 6 | Meaning |
---|---|---|
0 | 0 | bit error |
0 | 1 | form error |
1 | 0 | stuff error |
1 | 1 | other type of error |
Bit 5 | Meaning |
---|---|
0 | TX; error occurred during transmission |
1 | RX; error occurred during reception |
Bit 4..0 | Meaning |
---|---|
0x03 | start of frame |
0x02 | ID.28 to ID.21 |
0x06 | ID.20 to ID.18 |
0x04 | bit SRTR |
0x05 | bit IDE |
0x07 | ID.17 to ID.13 |
0x0F | ID.12 to ID.5 |
0x0E | ID.4 to ID.0 |
0x0C | bit RTR |
0x0D | reserved bit 1 |
0x09 | reserved bit 0 |
0x0B | data length code |
0x0A | data field |
0x08 | CRC sequence |
0x18 | CRC delimiter |
0x19 | acknowledge slot |
0x1B | acknowledge delimiter |
0x1A | end of frame |
0x12 | intermission |
0x11 | active error flag |
0x16 | passive error flag |
0x13 | tolerate dominant bits |
0x17 | error delimiter |
0x1C | overload 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
so it is likely that the module transmitting the message doesn't get any answer.