Conversation
dylad
left a comment
There was a problem hiding this comment.
Spotted a typo. Feels feel to squash directly.
58dc586 to
5a28f45
Compare
|
Should we provide a way to unblock it btw ? Or leave it to the user ? |
|
You probably want to unblock that again in |
5a28f45 to
c48525f
Compare
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.
c48525f to
b6ebdfe
Compare
|
I moved the |
Pull Request is not mergeable
|
Thx :-) |
|
Backport provided in #21184 |
|
This PR was not merged correctly. The commit that got merged was no longer part of the PR at the time of merge. |
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 anyRIOT output with
masterRIOT output with this PR
Conclusion
In both
masterand 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
None