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?
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:
If the issue doesn't replicate, you can also try the following steps:
Questions: