I would like to ask if anyone has successfully enabled the CAN feature on the Xavier? With Jetpack 3.2, I was able to use CAN on TX2 with SN65HVD230 transceiver, and enable CAN channel with these commands on terminal:
sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan
sudo ip link set can0 type can bitrate 500000 dbitrate 2000000 berr-reporting on fd on
sudo ip link set up can0
The document said Xavier also use MTTCAN, so I am in high hope that everything will the same from TX2. If anyone has implemented CAN on Xavier with its latest Jetpack, can you share your experience?
Yes, CAN is verified on Xavier.
And the software configuration is different than that of TX2.
There is a catch here.
At present (In case of Xavier) the pinmux which is packaged for Xavier on public releases, configures the CAN I/O pins to have GPIO functionality.
This is to comply with Raspi 40-pin standard.
In this case CAN functionalities are disabled on the pins.
To have the pins configured as CAN (SFIO) functionalities, either of these can be followed.
There is a separate pinmux configuration to be used in flashing.
Pinmux name: $TEGRA_TOP/ hardware/nvidia/platform/t19x/galen/bct/pinmux/tegra19x-mb1-pinmux-p2888-slvs-0000-a00-p2822-0000-a00.cfg
corresponding register values can be overwritten after the system boots.
Reg Val
0x0c303000 = 0x0000c400;
0x0c303008 = 0x0000c458;
0x0c303010 = 0x0000c400;
0x0c303018 = 0x0000c458;
Any reg read/write tool can be used to overwrite.
However in 2nd case, the register configurations will not be persistent across reboots.
Please let us know if you need any further information.
Thanks for replying. I am on the learning curve about all Jetson devices, so please bear with my basic questions. Are the configurations as you mention applied even when using Nvidia development kit?
I refer to the development kit document, and the expansion header pinout indicate the CAN pins which gave me the impression that the CAN pins is ready to be used on the development kit. Correct me if I misunderstood it there. For TX2 development kit, it doesn’t require any special config after flashing with Jetpack 3.2 except the few commands on the first post.
That is correct. For TX2, the flashing config itself uses the right pinmux config which configures all the pins to their respective SFIO functionalities.
In case of Xavier(T194 SoC), the default pinmux config file configures gpio mode instead of SFIO mode.
Hence it is required to flash with a separate pinmux (which configures all pins to SFIO mode) or dynamically the registers can be overwritten to configure the desired SFIO mode.
In case of CAN on Xavier, the registers are as per the previous comments.
How, specifically, would I go about using the separate pinmux instead of the default pinmux, when using flash.sh using the JetPack installation?
Do I change any configuration files? If so, which files, and how?
Do I change any command line options to flash.sh? If so, which?
From Xavier onward, default pinmux configuration will configure the 40-pin expansion header as GPIO (as much as possible) to comply with raspi 40-pin interface.
At present the discussion is on going to package and release another pinmux configuration which will configure 40-pin in its SFIO mode.
And separate instructions will be published in the customer documents regarding how to flash with SFIO pinmux configuration.
Can anyone confirm that this solution works? I have tried both suggestions from Sparta and have not been able to successfully use the canbus.
I set the register entries,
With the above setup it is observed that can communication is achieved over 2 tegra can controllers on Xavier.
From your logs of can initial state and datalink being silent, it seems there is any kind of configuration or setup problem.
Can you please try to read back the can din and dout regs just to double conform that the regs values are set properly?
Also please let us know what type of transceivers are being used at your setup and how are they interfaced with the controller in/out pins?
We are using a 2 TJA1057GT/3J. I can confirm that I have the registry entries set as stated above.
I can provide a drawing, but the mapping on that chip is
can0
1: 40-pin header Pin 31 GPIO/CAN1 Bus w/10kohm pullup to 3.3v
2: GND
3: 5v
4: 40-pin header Pin 39 GPIO/CAN1 Bus
5: 3.3v
6: CAN L
7: CAN H
8: GND
can1
1: 40-pin header Pin 33 GPIO/CAN1 Bus w/10kohm pullup to 3.3v
2: GND
3: 5v
4: 40-pin header Pin 37 GPIO/CAN1 Bus
5: 3.3v
6: CAN L
7: CAN H
8: GND
@LordObsidian01 I have no comment on the scheme because I don’t have an Xavier yet to try. But a lot of times, data did not go through for me due to missing the 120ohm terminal resistor at hardware level (this happens when trying to read external device from TX2). If that’s the case, data still comes in but fall into Error. This can be observed in the RX Error number in “ifconfig”. Probably that’s something to confirm too if you haven’t.
Yes. CAN bus is compulsory to have a terminating resistor of 120ohm.
Otherwise the network will be unmatched and the packets will be reflected back or corrupted. To match the impedance, you need to connect the resistor.
I just finished RX/TX communication test with two TJA1050 modules and an Xavier.
I connected two TJA1050s’ CAN_H and CAN_L, connected CAN0_DIN/CAN1_DIN to TJA1050S’ RXD and CAN0_DOUT/CAN1_DOUT to TJA1050S’ TXD.TJA 1050 needs a 5V power supply so connect power and ground as well.
Software instrustions please refer to https://github.com/hmxf/can_xavier for more detail.I’ll upload my easy_config scripts to this repo too.
@Sparta, to follow up on the issue that I was seeing, your suggestion does, in fact, solve the issue. I had an issue with the layout on the pcb for my transceiver and once that was resolved CAN communication works as expected, thanks!
I tried RX/TX communication test with two TJA1050 modules and an Xavier, CAN0/CAN1 can receive the message with each other. However, when I tried to use CANalyst-II to receive the message, I cannot receive anything, by the way, CANalyst-II could receive the radar message. I’d like to know whether I missed something when I configured the Xavier.
The blob which contains pinmux configuration gets generated on the fly and then flashed at a later point. It will not be straight forward to update/flash only the corresponding partition where pinmux changes are present, neither it is supported from the flash command directly.
If you still want to make the job easy without disturbing the complete setup, you can use a script which writes the values to the required registers and let the script run at system start up (like an init script does)