Errors
Normative
The error and return codes a conformant CAN driver reports. Development errors are only raised
when development error reporting is enabled (see enable_development_error_reporting in
Configuration Reference). Governed by CHI-CAN-MUST-21 and CHI-CAN-MUST-22 in Can — Requirements.
Development errors
When development error reporting is enabled, each API detects the conditions below and raises the listed error.
API |
Condition |
Error id |
|---|---|---|
|
Driver not in |
|
|
|
|
|
Driver not in |
|
|
Driver not initialized |
|
|
Invalid mailbox id |
|
|
|
|
|
Length > 64 bytes; or > 8 bytes on a non-FD channel; or > 8 bytes without the FD flag set |
|
|
Driver not initialized |
|
|
|
|
|
Invalid state transition requested |
|
|
|
|
|
Channel not in |
|
Development error type
Available via: CanIf_DriverTypes.h. Vendor-specific error definitions MUST be provided
via Can.h instead.
Runtime errors
Runtime errors are reported via LogM_Report with runtime-error log level.
Error id |
Reported when |
|---|---|
|
A received frame is lost (overwrite or FIFO overrun), where the hardware can detect it (optional, CHI-CAN-MAY-02). |
|
An unrecoverable channel HW error is detected (CHI-CAN-MUST-22). |
Runtime error type
Defines
-
CAN_RTERR_DATALOST (1U)
Received CAN message is lost
-
CAN_RTERR_UNRECOVERABLE (128U)
Error type that can not be recovered by the CanDrv itself. (e.g. CAN channel internal RAM ECC error)
-
CAN_RTERR_DATALOST (1U)
Available via: CanIf_DriverTypes.h. Vendor-specific error definitions follow:
recoverable [0x02, 0x7F], unrecoverable [0x81, 0xFF].
Return-type extension
Overlaid return value of Std_ReturnType for CAN driver API Can_Transmit()
Defines
-
CAN_BUSY (2U)
Transmit request could not be processed because no transmit object was available
-
CAN_BUSY (2U)
The CAN_BUSY return value of Can_Transmit comes from this extension. Available via:
CanIf_DriverTypes.h.