cpu/samd5x/periph_can: fix RX

[maribu]

Contribution description

CAN required CLK_CANx_APB and CLK_CANx_APB to be running and will not request any clock by itself. We can ensure both clocks to be running by preventing the MCU from entering IDLE state.

The SAMD5x/SAME5x Family Data Sheet says in Section "39.6.9 Sleep Mode Operation" says:

The CAN can be configured to operate in any idle sleep mode. The CAN
cannot operate in Standby sleep mode.

[...]

To leave low power mode, CLK_CANx_APB and GCLK_CANx must be active
before writing CCCR.CSR to '0'. The CAN will acknowledge this by
resetting CCCR.CSA = 0. Afterwards, the application can restart CAN
communication by resetting bit CCCR.INIT.

tl;dr: At most SAM0_PM_IDLE is allowed while not shutting down the CAN controller, but even that will pause communication (including RX).

Apparently, the CAN controller was never tested without also using the USB peripheral, which kept the clocks running as side effect.

Testing procedure

Set up USB CAN stick

$ sudo slcand /dev/ttyACM0 # <-- only needed for serial CAN adapters such as https://canable.io/ (or it's cheap clones from AliExpress)
$ sudo ip link set can0 up type can bitrate 500000

Sending to the SAME54-XPRO from Linux

$ cansend can0 '001#cafe'

Output of candump any

  can0  001   [3]  AB CD EF
  can0  001   [2]  CA FE

RIOT output with master

$ make BOARD=same54-xpro -C tests/drivers/candev flash term
[...]
   text	  data	   bss	   dec	   hex	filename
  20276	   128	 13432	 33836	  842c	/home/marian.buschsieweke@ml-pa.loc/Repos/software/RIOT/master/tests/drivers/candev/bin/same54-xpro/tests_candev.elf
[...]
Debugger: ATMEL EDBG CMSIS-DAP ATML2748051800006032 03.25.01B6 (S)
Clock frequency: 16.0 MHz
Target: SAM E54P20A (Rev A)
Programming...... done.
Verification........................................... done.
Done flashing
[...]
2025-01-31 22:13:40,156 # main(): This is RIOT! (Version: 2025.04-devel-56-g775f59)
2025-01-31 22:13:40,158 # candev test application
2025-01-31 22:13:40,158 # 
2025-01-31 22:13:40,161 # Initializing CAN periph device
> send
2025-01-31 22:13:43,438 # send
> receive
2025-01-31 22:13:45,208 # receive
2025-01-31 22:13:45,210 # Reading from Rxbuf...

RIOT output with this PR

$ make BOARD=same54-xpro -C tests/drivers/candev flash term
[...]
2025-01-31 22:17:17,065 # main(): This is RIOT! (Version: 2025.04-devel-57-gd93f0-cpu/samd5x/can-fix-rx)
2025-01-31 22:17:17,067 # candev test application
2025-01-31 22:17:17,067 # 
2025-01-31 22:17:17,070 # Initializing CAN periph device
> send
2025-01-31 22:17:19,297 # send
> receive
2025-01-31 22:17:20,831 # receive
2025-01-31 22:17:20,833 # Reading from Rxbuf...
2025-01-31 22:17:22,548 # id: 1 dlc: hx data: 0xCA 0xFE 

Conclusion

In both master and this PR sending from RIOT was picked up on the Linux side. But sending from Linux to RIOT was not picked up by RIOT in master, but with this PR.

Issues/PRs references

None

[riot-ci]

Murdock results

✔️ PASSED

c48525f cpu/samd5x/periph_can: fix RX

Success	Failures	Total	Runtime
10271	0	10271	09m:44s

Artifacts

• Documentation preview

[dylad]

Spotted a typo. Feels feel to squash directly.

[dylad]

Should we provide a way to unblock it btw ? Or leave it to the user ?

[benpicco]

You probably want to unblock that again in _power_off()

[maribu]

I moved the pm_block() and pm_unblock() to _power_on() and _power_off(). I also added a bitfield to track the state, so that code relying on powering on and off the CAN to be idempotent to still work. (E.g. powering it own twice and powering it of once every now and then would eventually overflow the blockers value, if we would increment the ref count twice and decrement the ref count only once.)

[maribu]

Thx :-)