CAN errors
The CANedge can detect and log errors on the CAN-bus if enabled in Logging. The detected errors are categorized as follows:
Bit-stuffing error
Form error
CRC error
Bit error
Acknowledge error
In general, once a node on the CAN-bus has detected an error, it will raise an error frame internally. Depending on the configuration and state of the node, this error frame may also be visible on the CAN-bus. The node can be in one of three states:
Active
Passive
Off
The transitions between the states depends on the number of detected errors in a sliding window. In the active state, the node is allowed to emit error frames onto the CAN-bus, while any detected error frames are kept internal in the passive state. In the off state the node is no longer receiving from or transmitting to the CAN-bus.
Note
The CANedge will return to the active state in case it ends in the off state.
With reference to the mode field, the following table of behavior is constructed for the CANedge:
Mode |
Normal |
Restricted |
Monitoring |
|||
|---|---|---|---|---|---|---|
State |
Active |
Passive |
Active |
Passive |
Active |
Passive |
Receive |
X |
X |
X |
|||
Transmit |
X |
|||||
Acknowledge |
X |
X |
||||
Internal error frames |
X |
X |
X |
X |
X |
X |
External error frames |
X |
|||||
The CANedge will log all errors it detects if error logging is enabled.
Note
The CANedge is not able to capture any additional CAN information once an error condition has been detected. As such, all logged error frames have no information about the associated CAN frame ID/flags/payload.
Bit-stuffing Errors
Under normal operation, no more than 5 consecutive bits of a frame may have the same value. If required, the sending node will insert additional stuffing bits to avoid this scenario. If the node detects a violation of this, a bit-stuffing error is raised.
All error frames emitted onto the CAN-bus are violations of the bit-stuffing rules. Thus, the true error need not be a bit-stuffing error, but since another node has detected an error, it will signal this to the rest of the bus by making the frame invalid.
Depending on whether the CANedge has detected the same error as the other node or not, a more informative error message may be logged. See example under acknowledge errors.
Form Errors
Form errors denote that the node has detected a missing or an invalid value in a fixed part of the CAN frame.
CRC Errors
If the node has calculated a different value for the cyclic redundancy check than the one embedded in the frame on the CAN-bus, a CRC error will be raised.
Bit Errors
When a node is transmitting a frame onto the CAN-bus, it can simultaneously sense what the actual value on the bus is. If the value differs from the expected value, a bit error is raised.
Acknowledge Errors
When the CANedge has transmitted a frame onto the CAN-bus, it expects another node on the bus to acknowledge the reception by filling a part of the frame. If no acknowledge is detected, the device raises an acknowledge error.
Example: If a node transmits a frame onto the bus and no other node acknowledges this via the ACK segment of the frame, that node will detect a missing acknowledge error. As a response, it will emit an error frame onto the bus, which causes the other nodes to detect a bit-stuffing error.
If the transmitting node had a transmission error counter of 0 before the transmission attempt, 16 error frames can be logged in rapid succession, as the node attempts to re-transmit the frame. After 16 attempts, the internal error counter of the transmitting node has reached 8 * 16 = 128, and the node enters the passive error state. The transmitting node is still detecting an error, as no other node acknowledges the transmitted frames, but it is no longer allowed to transmit active/dominant error bits.
As the original frame no longer is being destroyed by an error frame from the sender, the other nodes on the bus will now log the intended message, even though it is in an erroneous state due to the lack of acknowledgement.