Common mistakes

Informative

Pitfalls when using the CAN driver, and how to avoid them. Each maps to a rule in Can — Requirements or an error in Errors.

  • Transmitting before the channel is STARTED. Can_Transmit on a STOPPED channel is rejected. Start the channel first, and re-check state after a bus-off (the driver forces the channel to STOPPED).

  • Freeing the payload too early. The driver copies your data, but you must keep sduDataPtr valid until CanIf_OnTransmission fires. Freeing or overwriting it earlier risks sending stale data (CHI-CAN-MUST-09).

  • Stashing the RX pointer. Data given to CanIf_OnReception is valid only until the callback returns (CHI-CAN-MUST-15). Copy what you need; don’t keep the pointer.

  • Treating CAN_BUSY as an error. CAN_BUSY means the mailbox is busy, not that the call failed — retry later. Only E_NOT_OK indicates a development error.

  • Expecting automatic bus-off recovery. There is none (CHI-CAN-MUST-07). If you never call Can_SetChannelState(..., STARTED) after CanIf_OnError, the channel stays off the bus.

  • De-initializing while STARTED. Can_DeInit requires every channel to be STOPPED; otherwise it raises CAN_DEVERR_STATE_TRANSITION. Stop channels first.

  • Length that isn’t a valid DLC. The driver rounds up to the next valid DLC and pads (CHI-CAN-MUST-12) — make sure your object_payload_length and fd_padding_value are configured for the sizes you send.

  • Forgetting to service polled events. If you configured Polling for an event, you must call Can_PollFunction / Can_CyclicFunction cyclically, or that event is never handled.