Skip to content

R7FA6M5_CAN: CAN error interrupt handler incomplete — device stuck in infinite ISR loop on bus error #532

@lukasbraendli

Description

@lukasbraendli

Description

The CAN error interrupt callback onCanFDCallback in R7FA6M5_CAN.cpp is incomplete. When a CAN error occurs (e.g. the remote node disappears, causing the controller to enter error passive or bus-off state), the device becomes stuck in an infinite interrupt loop, making the CAN peripheral and the entire application unresponsive.

Root Cause

The error cases in onCanFDCallback only record the error in software:

_is_error = true;
_err_code = p_args->event;

However, they do not clear the hardware error flag register (CFDC_ERFL). Since these flags remain asserted, the interrupt line stays active and the ISR re-fires immediately upon returning, creating an infinite loop.

Unlike TX/RX complete events which are edge-triggered and cleared by the FSP layer, error conditions such as CAN_EVENT_ERR_PASSIVE and CAN_EVENT_ERR_BUS_OFF require explicit flag clearing in the handler.

Steps to Reproduce

  1. Set up a Portenta C33 transmitting CAN messages with error_interrupts enabled (i.e. the original value of CANFD_CFG_EXTENDED_CFG — not 0)
  2. Disconnect the remote CAN node or terminate the bus while the C33 is transmitting
  3. Observe the device hanging completely — no further code executes

Current Workaround

The only current workaround is to disable all error interrupts entirely in the extended config:

.error_interrupts = 0, // All errors are DISABLED

This prevents the hang but also means bus errors are never surfaced to the application, which is unacceptable for production use.

Expected Behaviour

Error interrupts should be handled correctly. At minimum the handler should:

  1. Clear the relevant hardware error flags (CFDC_ERFL) to de-assert the interrupt line and prevent re-entry
  2. For CAN_EVENT_ERR_BUS_OFF specifically, either temporarily mask the bus-off interrupt (BOEIE) and re-enable it upon CAN_EVENT_BUS_RECOVERY, or initiate a hardware recovery sequence
  3. Continue to notify the application layer via _is_error and _err_code as currently implemented

Environment

  • Board: Arduino Portenta C33
  • Core: ArduinoCore-renesas
  • Commit: 00910fde

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic: codeRelated to content of the project itselftype: imperfectionPerceived defect in any part of project

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions