Persistent Error State in can2040
zephyr-atomi opened this issue · comments
Description:
I've encountered a situation where can2040 consistently remains in an error state, rendering it non-operational. My custom error logs show the following:
xfguo: error(1) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(1) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(1) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(11) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(4) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(1) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(4) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(11) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(1) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(1) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(4) on msg: (id: 0, size: 0, data: 0, 0)
xfguo: error(11) on msg: (id: 0, size: 0, data: 0, 0)
How To Reproduce:
- Check out and compile my demo project created to reproduce this issue: https://github.com/zephyr-atomi/can2040-helloworld.
- Compile the binary and run it on the rp2040 chip.
- If there are existing messages being transmitted on the CAN bus (e.g., by socketcan continuously retransmitting due to missing ACKs), the RP2040 enters the error state described above.
If the issue doesn't replicate, you can also try the following steps:
- Load the ELF onto RP2040 using the picoprobe method. (you can use .vscode/launch.json to do this)
- Pause the RP2040's execution.
- From the PC side, send a message: cansend can1 002#DEADBEEF12346799. Since no one is receiving, it will keep retransmitting.
- Resume or restart the RP2040 program. It will then enter the aforementioned state.
Questions:
- Why is there such a high occurrence of errors in this case?
- Is this behavior expected?
- How can we systematically avoid entering this error loop?
That is possible due to the uart slowness, if I set the baud rate as 10K, the issue it gone.
Will close the issue. Thanks!