FLEXCAN Driver IRQ too slow?

[agj]

Hello,

I have a CAN based protocol where pings consists of two CAN frames, but for some reason the second frame is seemingly lost.

As can be seen on the photo, the two frames are very close to eachother, but from my debugging the flexcan driver callback is only called once on the first frame.

/2026-04-07/can-frames.jpeg 

Any subsequent pings seem to behave differently, as the photo below shows.

/2026-04-07/can-frames-2.jpeg

If I lower the CAN bitrate the issue seems to dissapear - this is not practical for me because all other devices on my bus are speaking 1Mbit/s, so I have to look elsewhere. I am using a fairly simple setup using LTC2875:

 

My device tree:

&flexcan1 {
	/* J7/10 (main bus) */
	status = "okay";
	pinctrl-0 = <&pinmux_flexcan1>;
	pinctrl-names = "default";
	phys = <&can_phy1>;

	can-transceiver {
		max-bitrate = <5000000>;
	};
};

&flexcan2 {
	/* J7/10 (main bus) */
	status = "okay";
	pinctrl-0 = <&pinmux_flexcan2>;
	pinctrl-names = "default";
	phys = <&can_phy2>;

	can-transceiver {
		max-bitrate = <5000000>;
	};
};

&flexcan3 {
	/* J9? */
	status = "okay";
	pinctrl-0 = <&pinmux_flexcan3>;
	pinctrl-names = "default";
	phys = <&can_phy3>;

	can-transceiver {
		max-bitrate = <5000000>;
	};
};

To me, it looks a bit like the flexcan driver's IRQ is doing a lot of stuff before lowering the "I have handled the event"-flag, which might be what is leading to this issue, but my attempts at patching it has not resulted in any improvement.

I am using zephyr version 4.3.0 and the upstream `hal_nxp` module (so version 2.14.4 of the flexcan driver)

[mayliu1]

Hi @agj ,

Thank you so much for your interest in our products and for using our community.

 I suggest you check below :

1: Check whether your Zephyr setup is using a single RX mailbox or the RX FIFO.

2: I  suggest using the RX FIFO or multiple RX mailboxes.

3: Please check for RX FIFO overflow or warning states.

The NXP SDK defines specific receive statuses such as  kStatus_FLEXCAN_RxFifoBusy,   kStatus_FLEXCAN_RxFifoOverflow,  and    kStatus_FLEXCAN_RxFifoWarning .

If you can add some logging and see overflow or warning conditions, that would  point to a buffering issue rather than a PHY or bitrate problem.

Please try it.

Best Regards

May Liu

[agj]

I tried enabling `CONFIG_CAN_STATS=y` (and `CONFIG_STATS=y`)... `can show can@400c4000` shows that an rx overrun occurred (see below). This is very odd to me considering the default amount of mailboxes is 64. I also noticed that I can only process 6 can frames at a time on the MCU...

```
uart:~$ can show can@400c4000
core clock: 24000000 Hz
max bitrate: 1000000 bps
max std filters: 10
max ext filters: 10
capabilities: normal loopback listen-only triple-sampling
mode: normal
state: error-active
rx errors: 0
tx errors: 0
timing: sjw 1..4, prop_seg 1..8, phase_seg1 1..8, phase_seg2 2..8, prescaler 1..256
transceiver: can-phy1
statistics:
bit errors: 0
bit0 errors: 0
bit1 errors: 0
stuff errors: 0
crc errors: 0
form errors: 0
ack errors: 0
rx overruns: 1
```

[agj]

Hi May,

You make it sound like RX FIFO and Mailboxes are mutually exclusive, is this correct?
By my research, it looks like mailboxes are enabled as the default (confirmed through a gdb session - I have 64 mailboxes) however, I don't see how to enable RX FIFO. Can you assist in how to enable RX FIFO in my zephyr project?

Best Regards,
Asger Gitz-Johansen

[mayliu1]

1：  64 mailboxes does not mean 64 active RX buffers .

FlexCAN supports 64 total mailboxes , but each mailbox can be configured as either Rx or Tx ， so the effective receive capacity depends on how the driver configures them, not just on the raw hardware count.

2:   Rx FIFO and Mailboxes are not simply mutually exclusive . The FlexCAN block includes both Mailboxes and an Rx FIFO, and the hardware supports selectable priority between Mailboxes and Rx FIFO during matching .

3: your observation that you can only process 6 frames at a time matches the documented Legacy Rx FIFO depth of 6 frames .