Controller Area Network (CAN) on Xavier AGX at 1Mbps

I could follow these steps (To use PLLAON as clock source with Updating the clock frequency in Device tree on jetson nx / Setup CAN with PLLAON as clock source) on my jetson Xavier (JetPack 4.5.1, NV Power Mode: MAXN), but if I check the pll_source, it is still osc.

If I open /sys/kernel/debug/bpmp/debug/dt on the jetson, I see allowed-parents = <0x121 0x5b 0x5e 0x13a>

On my host pc: tegra194-p2888-0001-p2822-0000.dtb

$ dtc -I dtb -O dts -f tegra194-p2888-0001-p2822-0000.dtb -o tegra194-p2888-0001-p2822-0000.dts

pll_source = “pllaon”;
clocks = <0x4 0x11c 0x4 0xa 0x4 0x9 0x4 0x5b 0x4 0x5e>
clock-names = “can_core”, “can_host”, “can”, “osc”, “pllaon”;

clocks-init{
…
disable{
clocks = <0x4 0x9 0x4 0xb>;
};
};

$ dtc -I dts -O dtb -f tegra194-p2888-0001-p2822-0000.dts -o tegra194-p2888-0001-p2822-0000.dtb

Flash…Check on Jetson

$ xxd /proc/device-tree/mttcan@c310000/clocks
00000000: 0000 0004 0000 011c 0000 0004 0000 000a …
00000010: 0000 0004 0000 0009 0000 0004 0000 005b …[
$ sudo cat /sys/kernel/debug/bpmp/debug/clk/can1/parent
osv
$ sudo cat /proc/device-tree/mttcan@c310000/pll_source
osc

/sys/kernel/debug/bpmp/debug/clk/can1# cat possible_parents
clk_32k osc pll_aon pll_c

$ dtc -I fs /sys/firmware/devicetree/base | less

mttcan@c310000 {
compatible = “nvidia,tegra194-mttcan”;
clocks = <0x4 0x11c 0x4 0xa 0x4 0x9 0x4 0x5b>;
resets = <0x5 0x4>;
reg-names = “can-regs”, “glue-regs”, “msg-ram”;
clock-names = “can_core”, “can_host”, “can”, “osc”;
rx-config = <0x40 0x40 0x40>;
pll_source = “osc”;
mram-params = <0x0 0x10 0x10 0x20 0x0 0x0 0x10 0x10 0x10>;
status = “okay”;
interrupts = <0x0 0x28 0x4>;
phandle = <0x185>;
reg = <0x0 0xc310000 0x0 0x400 0x0 0xc311000 0x0 0x32 0x0 0xc312000 0x0 0x1000>;
reset-names = “can”;
linux,phandle = <0x185>;
tx-config = <0x0 0x10 0x0 0x40>;
};
clocks-init {
compatible = “nvidia,clocks-config”;
status = “okay”;

disable {
clocks = <0x14d 0x5e 0x4 0x9 0x4 0xb>;
};
};

Thanks for any help!

1 Like

Typo, this is what I get from the output…

$ sudo cat /sys/kernel/debug/bpmp/debug/clk/can1/parent
osc

Please remove osc and respective 0x4 0x5b instance.
It should look like:
clocks = <0x4 0x11c 0x4 0xa 0x4 0x9 0x4 0x5e>
clock-names = “can_core”, “can_host”, “can”, “pllaon”;

tegra194-p2888-0001-p2822-0000.dtb file

  1. *.dtb → *.dts
  2. Update changes from @shgarg
  3. *.dts → *.dtb
  4. sudo ./flash.sh -r -k kernel-dtb jetson-agx-xavier-devkit mmcblk0p1
    sudo ./flash.sh -r -k kernel-dtb_b jetson-agx-xavier-devkit mmcblk0p1

This flashing process is correct?
In Line 104 output_flash_command.txt (48.3 KB), what does this copy to *.dtb.rec mean?

The clock is still osc…

$ xxd /proc/device-tree/mttcan@c310000/clocks
00000000: 0000 0004 0000 011c 0000 0004 0000 000a …
00000010: 0000 0004 0000 0009 0000 0004 0000 005b …[

$ cat /proc/device-tree/mttcan@c310000/pll_source
osc
$ cat /sys/kernel/debug/bpmp/debug/clk/can1/parent
osc
$ cat /sys/kernel/debug/bpmp/debug/clk/can1/possible_parents
clk_32k osc pll_aon pll_c

Use this:
sudo ./flash.sh -k kernel-dtb jetson-agx-xavier-devkit mmcblk0p1

I tried your command (output_flash_command_v2.txt (51.6 KB))

$ cat /proc/device-tree/mttcan@c310000/pll_source
osc
$ cat /sys/kernel/debug/bpmp/debug/clk/can1/parent
osc

It is still the standard clock…

Before flashing, check if the dtb has pllaon in mttcan node. Use fdtdump command and check. If it is pllaon then flashing is not updating dtb.

$fdtdump tegra194-p2888-0001-p2822-0000.dtb >> output.txt
output.txt (557.4 KB)

It looks correct.

First check by loading mttcan driver:
cat /sys/kernel/debug/bpmp/debug/clk/can1/parent
if it still does not say pllaon,
Can you try flashing the full image once? I am not sure which component has changed due to earlier flash commands. Then again, after flash, when you load mttcan driver, check clock after loading mttcan driver.

Also, you need to enable pllaon clock in bpmp dtb as per document instructions, have you done that?

Yes, the bpmp dtb looks fine. See my first post.

Ok, bpmp and kernel-dts are looking fine.
Please let me know the results of my earlier comment.
First check by loading mttcan driver:
cat /sys/kernel/debug/bpmp/debug/clk/can1/parent
if it still does not say pllaon,
Can you try flashing the full image once? I am not sure which component has changed due to earlier flash commands. Then again, after flash, when you load mttcan driver, check clock after loading mttcan driver.

I read, that this inaccuracy shouldn’t be a problem for our peripherie. So I tried to measure my signal with the standard clock and this configuration:

10: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100
bitrate 1010526 sample-point 0.736
tq 52 prop-seg 6 phase-seg1 7 phase-seg2 5 sjw 1
mttcan: tseg1 2…255 tseg2 0…127 sjw 1…127 brp 1…511 brp-inc 1
mttcan: dtseg1 1…31 dtseg2 0…15 dsjw 1…15 dbrp 1…15 dbrp-inc 1
clock 38400000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0

The baud rate should be around 1’000’000 (1 Mbps), but it is by factor 3 smaller. The time of one bit should be 1 us and not 3 us.

I am also seeing this problem, did you find a solution?

@che It looks like the JETPACK 4.4 is correct.
jetpack4.4_CAN

@shgarg I flashed the full image once again (JETPACK 4.4. with the SDK Manager 1.6.0.8170) and tried to change the clock speed (with the steps from my first post), but it still does not work…

Hi ,
To work at 1Mbps, change to pllaon: https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/clocks.html#wwpID0E06B0HA

check if exact bitrate got set from:
ip -d -s link show can0

Let me know where exactly you are stuck.

@fabkus what version of Jetpack did you encounter this problem with? I have the same issue with JETPACK 4.6. Am I correct in understanding that JETPACK 4.4 doesnt have this problem?