-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpu/samd5x/periph_can: fix RX [backport 2025.01] #21184
cpu/samd5x/periph_can: fix RX [backport 2025.01] #21184
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK. I guess we add it and do a basic retest...
I will also manually add it to the release notes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a backport and fixes a realy anoing bug and therefor should be moved in even though it has issues
I removed this from the merge queue for now. The issue is that Github merged an old state of the PR backported here. But this backport did indeed correctly pick the commit that should have been merged to |
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.
1ea14e8
to
97006a8
Compare
I updated this to the commit that actually got merged into |
Backport of #21181
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:
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
Sending to the SAME54-XPRO from Linux
Output of
candump any
RIOT output with
master
RIOT output with this PR
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 inmaster
, but with this PR.Issues/PRs references
#21181