CAN-Bus Enable

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hi.

I want to enable can bus on Jetson TX2.
I followed the NVIDIA Jetson Linux Developer Guide, Enabling CAN section:

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/hw_setup_jetson_can.html#wwpID0E0SD0HA

I have two questions:

1- I don’t know how to do this In the Pinmux section :
Update the respective platform pinmux configuration files and flash the updated files.

2- Is the procedure described in Pinmux section equivalent to editing these lines of device tree and re-flashing? (I know the changes made by devmem will persist only until the system is rebooted.)

mttcan@c310000 {
                 ...........
                status = "okay";
                ............
        };

mttcan0-ivc {
		compatible = "bosch,mttcan-ivc";
		mboxes = <0x41 0x3>;
		status = "okay";
	};

Thanks.

CAN Driver for TX2
#3

Is the following procedure OK for enabling CAN?

1- Changing the spreadsheet. I see nowhere in excel file that need to be changed for CAN-bus enable. It seems that two CAN-bus are enabled by default. Correct me if I am wrong.
2- Generating three dtsi files
3- Convert them to a .cfg file using:

python pinmux-dts2cfg.py --pinmux addr_info.txt gpio_addr_info.txt por_val.txt --mandatory_pinmux_file mandatory_pinmux.txt \
    tegra18x-jetson-tx2-default-template-pinmux.dtsi \
    tegra18x-jetson-tx2-default-template-gpio-default.dtsi 1.0 \
    > ../../../bootloader/t186ref/BCT/tegra186-mb1-bct-pinmux-quill-p3310-1000-<version>.cfg

in the Linux_for_Tegra/kernel/pinmux/t186/ directory.

4- Re-flashing the whole Jetson device (Not a specific partition).

#4

I get these errors when running the pinmux-dts2cfg.py file:

ERROR: pin dap2_sclk_pc1(0x00000440) field nvidia,enable-input(0x00000040) is not matching, val = 0x01 expected = 0x00
ERROR: pin dap2_fs_pc4(0x00000440) field nvidia,enable-input(0x00000040) is not matching, val = 0x01 expected = 0x00
ERROR: pin dmic1_clk_pm1(0x00004441) field nvidia,enable-input(0x00000040) is not matching, val = 0x01 expected = 0x00
ERROR: pin dmic2_dat_pm2(0x00004441) field nvidia,enable-input(0x00000040) is not matching, val = 0x01 expected = 0x00
ERROR: pin dap4_sclk_pcc0(0x00004440) field nvidia,enable-input(0x00000040) is not matching, val = 0x01 expected = 0x00
ERROR: pin dap4_fs_pcc3(0x00004440) field nvidia,enable-input(0x00000040) is not matching, val = 0x01 expected = 0x00
ERROR: pin sdmmc4_dqs(0x00000444) field nvidia,tristate(0x00000010) is not matching, val = 0x00 expected = 0x01
#5

Follow below document to get the kernel and device source code to do the modification.
Suppose pinmux-dts2cfg.py doesn’t matter with enable CAN

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/kernel_custom.html#

#6

I get the errors I posted when i run pinmux-dts2cfg.py

No any comment?

#8

Hi AliHaeri,

The –mandatory_pinmux_file is the optional:
--mandatory_pinmux_file MANDATORY_PINMUX_FILE_NAME is optional pinmux values info file

You can run below command to skip that errors:

python pinmux-dts2cfg.py --pinmux addr_info.txt gpio_addr_info.txt por_val.txt tegra18x-jetson-tx2-default-template-pinmux.dtsi tegra18x-jetson-tx2-default-template-gpio-default.dtsi 1.0 > ../../../bootloader/t186ref/BCT/tegra186-mb1-bct-pinmux-quill-p3310-1000-<version>.cfg
#9

Thanks carolyuu

The errors did not appear when using your suggested command, but no .cfg file was generated in
Linux_for_Tegra/kernel/pinmux/t186 directory.

#10

It will overrides the tegra186-mb1-bct-pinmux-quill-p3310-1000-.cfg at …/Linux_for_Tegra/bootloader/t186ref/BCT

#11

Thanks ShaneCCC

Would you please tell me what changes are required to Pinmux spreadsheet to enable CAN-bus?

It seems that they are enabled by default in the downloaded excel file.

#12

Should be below pins in the xml file. But I don’t have idea what need to modify.
Maybe have a check the REG by devmem/devmem2 to confirm the config.

J26 (30-pin header):

CAN0_RX: [5]

CAN0_TX: [7]

CAN1_RX: [15]

CAN1_TX: [17]

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/hw_setup_jetson_can.html#wwpID0E06D0HA

#13

I checked the registers with devmem tool, and the registers are as shown in the table :

image
image833×571 12.4 KB

The loop-back test does not work. No signal on oscilloscope.
Jetpack Version: 4.5.1

I carefully read the instructions but no success.

#15

Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks

#16

Hi

Yes I flashed a new OS and followed the instructions, and it works.

There is no need to change Pinmux spreadsheet or device tree…

only the following steps according to the Jetson Linux Develper Guide will be OK:

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3251/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/hw_setup_jetson_can.html#

1- sudo modprobe can
2- sudo modprobe can_raw
3- sudo modprobe mttcan
4- sudo ip link set can0 up type can bitrate 500000 loopback on
5- connect RX pin to TX pin (Pin 5 and 7 of J26)
6- candump can0
7- in another command window: cansend can0 123#AABBCCDDAABBCCDD

And you will be able to see the transmitted data below the candump.

An important point, which I found others like me make the same mistake:

If you do not connect TX to RX, the CAN controller sends the first message via TX pin and do not receive the same bytes via its RX pin. This makes the CAN controller to think that there is a fault on the bus, probably a CAN_ERROR occures, and after that, the CAN controller will not send any message on the bus until the error is deleted.

So, you will not be able to see anything even on the oscilloscope, if you did not connect TX to RX.

In a standard CAN bus, there is a CAN transceiver (which is not present on DevKit). The CAN transceiver is designed such that it reflects to the CAN RX pin any data present on the bus, no matter the bit was sent by the same node or by another node.

Another point is if you connect RX to TX pin, and do no turn loopback on, the CAN controller sends the message over and over, because there is not any other node on the bus which makes the ACK bit dominant. The transmitter node sends the message repeatedly until it is acknowledged by another node. The loopback test virtually acknowledges the CAN message.

Hope this will be useful.

Thank you ShaneCCC and kayccc for the support.

1 Like
#18

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.