Hello,
in our device we are using 2 CAN controllers, one on the SoM verdin imx8m-mini, the other on our carrier board.
the controller on the carrier board is the same microchip mcp2518fd used on the SoM.
When we were using rev1.1B of the SoM both CAN controllers were using 2 crystal@20MHz as clocks. in this situation my loop test between the two CAN controllers is working fine (send a fixed packet from one controller to the other and parse the expected packet)
Recently we have started using rev1.1D of the SoM on which the crystal clock has been changed to 40MHz
I have changed the settings on the devicetree, I can communicate properly with devices connected to the CAN controller on the SoM, but my loop test with the CAN controller on the carrier board (which still uses a 20MHz crystal) is now failing,
I guess changing the clock frequency on the SoM has affected the bit-timing, but how do I accommodate the changing in the device tree?
these are the current settings for both controllers in my devicetree:
ip -details link show can0 type can
should confirm clock specified in DT.
Do you have issues with arbitration bit rate or dat bit rate. For frames with BRS=1 tq and dtq should be the same.
this is top value for 20MHz. With 40MHz clock it can be 40/2 * 0.85 = 17MHz
This means your changes to .dts files didn’t end in DT. Perhaps dts files wasn’t patched by Yocto, old *.dtb is installed in target or any other similar issue.
As you see, since driver uses same 40MHz clock you see identical tq (time quantas) on both and the same amount of time quanta in all bit time segments.
Hm, since cat /sys/kernel/debug/clk/clk_summary reports fixed clocks by they name in DT, “oscillator” in your case, not reference name “clk40m”, then perhaps 2nd oscillator instance is just the same instance with overwritten clock-frequency? Please check your clk_summary, you should see two oscillator instances if both, 20 and 40MHz clocks are used on the same board. If it’s the case ( I’m not really sure and hope it’s not so), then dtb compiler clearly should not allow multiple reference names for the same object.
Looks like it is nice timebomb for unexperienced DT programmers. No DT compiler warnings, no errors and a very good chance for hours of hair picking.
Code below gives resulting clock of 40M in single MCP2518FD instance, though at first glance 20M is used in code. clk_summary reports single “oscillator” instance, so one oscillator is overwritten by another oscillator. Interestingly, you can’t do something like `clk20m: clk40m: oscillator {};" but can cheat it on purpose if you want two names for the same thing.