-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Add support for stm32u5 fdcan #45216
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
Add support for stm32u5 fdcan #45216
Conversation
|
Does this pass the CAN driver tests ( |
Unfortunately, my development environment is on Windows so I am unable to run tests using twister. |
You can build and flash the test applications just like any other application and examine the console output. No need for twister. I am mainly interested in the timing tests as you are introducing a new core CAN clock here. If the timing tests all pass (and the produced bitrate is correct), we know this change is okay. |
All of the tests pass (see below). There are two caveats to consider:
As an aside, while the generated timings work on my bench set up, I don't like how large the segments Tq are compared to the SJW (in my case 1). Historically, I've always preferred to keep the total number of Tq to 16, since it allows for a single SJW to cover a large range of clock issues. I can of course manually configure my timing how I please, but is there a reason why the calculator uses so many Tq? |
Thanks, fixed in #45220
You are right, that does seem rather high. I have just verified on a
The CAN core clock (160MHz) is very high? On the |
|
Test suite results running from the 24 MHz HSE clock. |
henrikbrixandersen
left a comment
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.
Looks good from a CAN point of view. I'll leave the SoC specific stuff to @erwango.
erwango
left a comment
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.
One tiny comment.
Otherwise, I'd suggest to squash first and third commit for clarity.
88edeb9
393ad3d to
88edeb9
Compare
The STM32u% series of processors has a unique set of clock sources for the FDCAN peripheral. This brings the selection in line with the existing can_stm32fd clock selection Kconfigs. This change was tested on a proprietary board using the STM32U5 series which exposes the CAN pins of the SOC using a transciever on a live CAN bus as well as on the nucleo_g474re board from ST in loopback mode. HSE and PLL1Q tests run and all passed. PLL2P is not currently supported by the clock drivers for STM32U5, and as such is currently untested. When this support is added, the driver should be able to use this clock without issue. When changes from zephyrproject-rtos#42097 are merged this fix should be deprecated in favor of using the methods outlined there. Signed-off-by: Peter Maxwell Warasila <[email protected]>
Add support for the fdcan peripheral to the stm32u5 series device tree include. This can be applied here since (at present) all of the stm32u5 series MCUs have an FDCAN peripheral. Signed-off-by: Peter Maxwell Warasila <[email protected]>
88edeb9 to
645cbe0
Compare
|
@henrikbrixandersen, @alexanderwachter mind approving once more ? |
In zephyrproject-rtos#45014 the m_can compatible identifier was changed from "m-can-base" to "m_can-base" while zephyrproject-rtos#45216 was being developed. This commit updates the dts for u5 to the latest format. Signed-off-by: Peter Maxwell Warasila <[email protected]>
In #45014 the m_can compatible identifier was changed from "m-can-base" to "m_can-base" while #45216 was being developed. This commit updates the dts for u5 to the latest format. Signed-off-by: Peter Maxwell Warasila <[email protected]>
In zephyrproject-rtos#45014 the m_can compatible identifier was changed from "m-can-base" to "m_can-base" while zephyrproject-rtos#45216 was being developed. This commit updates the dts for u5 to the latest format. Signed-off-by: Peter Maxwell Warasila <[email protected]>
This addresses #45123 in the near term.
Since the clock configuration on STM32 is set to change with #42097 in the future, this only supports clocking from PLL1Q, which should be sufficient for most applications.
Fixes: #45123