Skip to content
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

CAN0 Frequency issue #3

Open
mkleox opened this issue Oct 6, 2023 · 0 comments
Open

CAN0 Frequency issue #3

mkleox opened this issue Oct 6, 2023 · 0 comments

Comments

@mkleox
Copy link

mkleox commented Oct 6, 2023

The device tree seems does not considered the CAN0 clock source.
This makes the CAN to not run with the provided Device Tree after compilation of the debian kernel with the instructed docker.

this is a problem because when I set the CAN with the following command:

ip link set can0 type can bitrate 1000000

and the i bring the interface up with:

ip link set can0 up

and the the ifconfig shows:

can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 56 

but after I send some bytes to my connected device using this command:

cansend can0 001#FF

the can interface stops from running and in fact is not sending anything to the bus.
after running the cansend the if config shows this:

can0: flags=129<UP,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 5  bytes 40 (40.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 56 

After lots of debug, I found the CAN0 is not set correctly in the DT.

on the original precompiled image from Octavo, I have this:

root@osd32mp1-red:~# ip -details link show can0
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
	  bitrate 1000000 sample-point 0.750 
	  tq 41 prop-seg 8 phase-seg1 9 phase-seg2 6 sjw 1
	  m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-inc 1
	  m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp-inc 1
	  clock 24000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

but on the debian image that I compiled with the provided device tree:

$ ip -details link show can0
4: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state BUS-OFF (berr-counter tx 248 rx 0) restart-ms 0 
          bitrate 1003378 sample-point 0.743 
          tq 13 prop-seg 27 phase-seg1 27 phase-seg2 19 sjw 1
          m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-inc 1
          m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp-inc 1
          clock 74250000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

It seems the clock is not set correctly.
on the working image the clock is set to 24000000.
on the compiled image is set to: 74250000

When I run the following command on the image with the provided device tree:

cat /sys/kernel/debug/clk/clk_summary

shows:

ck_hse                               2        3        0    24000000          0     0  50000
    usbphy_k                          1        1        0    24000000          0     0  50000
    ck_per                            0        0        0    24000000          0     0  50000
       adc12_k                        0        0        0    24000000          0     0  50000
    pll4                              0        0        0   594000000          0     0  50000
       pll4_r                         0        0        0    74250000          0     0  50000
          fdcan_k                     0        0        0    74250000          0     0  50000
       pll4_q                         0        0        0    74250000          0     0  50000
          ltdc_px                     0        0        0    74250000          0     0  50000
          dsi_px                      0        0        0    74250000          0     0  50000
       pll4_p                         0        0        0    99000000          0     0  50000
          spdif_k                     0        0        0    99000000          0     0  50000
          sdmmc3_k                    0        0        0    99000000          0     0  50000
          sdmmc2_k                    0        0        0    99000000          0     0  50000
          sdmmc1_k                    0        0        0    99000000          0     0  50000

while in the image provided in the octavo website, it shows:

ck_hse                               4        5        0    24000000          0     0  50000
    fdcan_k                           0        0        0    24000000          0     0  50000
    usbphy_k                          1        1        0    24000000          0     0  50000
    ck_per                            0        0        0    24000000          0     0  50000
       adc12_k                        0        0        0    24000000          0     0  50000
    pll4                              2        2        0   594000000          0     0  50000
       pll4_r                         0        0        0    74250000          0     0  50000
       pll4_q                         1        1        0    29700000          0     0  50000
          ltdc_px                     1        1        0    29700000          0     0  50000
          dsi_px                      0        0        0    29700000          0     0  50000
       pll4_p                         1        1        0    99000000          0     0  50000
          sdmmc3_k                    2        2        0    99000000          0     0  50000
          sdmmc2_k                    0        0        0    99000000          0     0  50000
          sdmmc1_k                    0        0        0    99000000          0     0  50000

Any suggestion how to fix this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant