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
- Set up a Portenta C33 transmitting CAN messages with
error_interrupts enabled (i.e. the original value of CANFD_CFG_EXTENDED_CFG — not 0)
- Disconnect the remote CAN node or terminate the bus while the C33 is transmitting
- 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:
- Clear the relevant hardware error flags (
CFDC_ERFL) to de-assert the interrupt line and prevent re-entry
- 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
- 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
Description
The CAN error interrupt callback
onCanFDCallbackinR7FA6M5_CAN.cppis 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
onCanFDCallbackonly 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_PASSIVEandCAN_EVENT_ERR_BUS_OFFrequire explicit flag clearing in the handler.Steps to Reproduce
error_interruptsenabled (i.e. the original value ofCANFD_CFG_EXTENDED_CFG— not0)Current Workaround
The only current workaround is to disable all error interrupts entirely in the extended config:
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:
CFDC_ERFL) to de-assert the interrupt line and prevent re-entryCAN_EVENT_ERR_BUS_OFFspecifically, either temporarily mask the bus-off interrupt (BOEIE) and re-enable it uponCAN_EVENT_BUS_RECOVERY, or initiate a hardware recovery sequence_is_errorand_err_codeas currently implementedEnvironment
00910fde