We aim to expand the CAN function on Thor via SPI, using the CH9431 chip. The circuit diagram for the test board is as follows:CH9431T-R0-1v0.pdf (68.8 KB)
When we connected it to the T5000 module for testing, we found that the SPI driver failed to register successfully. The T5000 also uses our self-developed carrier board, and the SPI-related circuits are exactly the same.
And the drivers are exactly the same. And it can be compiled successfully in the T5000 source code.
Based on the error message from the driver, it seems that T5000 failed to establish communication with the CH9431 chip.
Could you please provide some good suggestions to facilitate the troubleshooting process?
Additionally, on the T5000, we successfully expanded the serial port via SPI, using the same brand of chip, CH9434.
I added the patch file as described in the aforementioned link. The log of loading the driver is as follows:
[ 81.751436] ch9431 spi0.0: ----plink----spi->max_speed_hz: 12000000
[ 81.751454] ch9431 spi0.0: ----plink----spi->mode: 3
[ 81.756631] spi-tegra114 810c590000.spi: msg: single xfer, cs_change=0 -> use_hw_cs=1
[ 81.757326] spi-tegra114 810c590000.spi: setup_xfer: using HW CS, cmd1=0x70400007
[ 81.757402] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 81.757405] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70400807
[ 81.781127] spi-tegra114 810c590000.spi: msg: scan xfer[0] len=2 cs_change=0 is_last=0
[ 81.781141] spi-tegra114 810c590000.spi: msg: scan xfer[1] len=1 cs_change=0 is_last=1
[ 81.781143] spi-tegra114 810c590000.spi: msg: multi xfer -> use_hw_cs=1
[ 81.781152] spi-tegra114 810c590000.spi: setup_xfer: using HW CS, cmd1=0x70400007
[ 81.781515] spi-tegra114 810c590000.spi: xfer done: intermediate, cs_change=0, CS stays asserted
[ 81.781556] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 81.781559] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70401007
[ 81.784964] spi-tegra114 810c590000.spi: msg: scan xfer[0] len=2 cs_change=0 is_last=0
[ 81.784977] spi-tegra114 810c590000.spi: msg: scan xfer[1] len=1 cs_change=0 is_last=1
[ 81.784980] spi-tegra114 810c590000.spi: msg: multi xfer -> use_hw_cs=1
[ 81.784988] spi-tegra114 810c590000.spi: setup_xfer: using HW CS, cmd1=0x70400007
[ 81.785042] spi-tegra114 810c590000.spi: xfer done: intermediate, cs_change=0, CS stays asserted
[ 81.785080] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 81.785082] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70401007
[ 81.812600] spi-tegra114 810c590000.spi: msg: scan xfer[0] len=2 cs_change=0 is_last=0
[ 81.812605] spi-tegra114 810c590000.spi: msg: scan xfer[1] len=1 cs_change=0 is_last=1
[ 81.812607] spi-tegra114 810c590000.spi: msg: multi xfer -> use_hw_cs=1
[ 81.812614] spi-tegra114 810c590000.spi: setup_xfer: using HW CS, cmd1=0x70400007
[ 81.812693] spi-tegra114 810c590000.spi: xfer done: intermediate, cs_change=0, CS stays asserted
[ 81.812727] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 81.812729] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70401007
[ 81.812737] ch9431 spi0.0: ch9431_hw_probe, CH9431_CTRL 0x20
[ 81.812744] ch9431 spi0.0: Cannot initialize ch9431. Wrong wiring?
[ 81.813111] ch9431 spi0.0: ch9431_probe failed, err=19
Hi chen.xi,
What’s the Jetpack version in use?
chen.xi:
The test carrier board of this chip. Using ORIN NX in conjunction with our self-developed board test function works perfectly.
When we connected it to the T5000 module for testing, we found that the SPI driver failed to register successfully.
Do you mean that you use the same custom carrier board for both Orin NX and Thor?
Can you share the block diagram of your connections and also the dmesg/device tree(as file) for further check?
nvidia@tegra-ubuntu:~$ cat /etc/nv_tegra_release
# R38 (release), REVISION: 4.0, GCID: 43443517, BOARD: generic, EABI: aarch64, DATE: Wed Dec 31 00:15:19 UTC 2025
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia
INSTALL_TYPE=openrm
It’s just that the circuitry for the SPI part is exactly the same, and the SPI slave devices attached to it are also exactly the same.
About dts:
spi@810c590000 {
status = "okay";
spi@0 {
//compatible = "tegra-spidev";
//reg = <0x1>;
//spi-max-frequency = <10000000>;
compatible = "wch,ch9431";
reg = <0x0>;
status = "okay";
spi-max-frequency = <120000000>;
#address-cells = <1>;
#size-cell = <1>;
interrupt-gpio = <&gpio_aon TEGRA264_AON_GPIO(DD, 4) IRQ_TYPE_LEVEL_LOW>;
controller-data {
nvidia,enable-hw-based-cs;
nvidia,rx-clk-tap-delay = <0x10>;
nvidia,tx-clk-tap-delay = <0x0>;
};
};
};
complete files:dmesg.log (114.1 KB)device_tree.zip (47.5 KB)modify_driver.zip (24.1 KB)
Equipment connection diagram. Please wait a moment.
Thanks for your sharing.
Could you also share the full dmesg before applying the change ?
[ 49.044901] ch9431 spi0.0: ch9431_hw_reset, ch9431 didn't enter in conf mode after reset
[ 49.045116] ch9431 spi0.0: ch9431_probe failed, err=110
[ 49.045128] ch9431: probe of spi0.0 failed with error -110
Have you tried adding some debug messages in custom wch,ch943 driver?
It seems you are using GPIO09(i.e. PDD.04) as the interrupt.
Log entry as follows:
[ 82.410218] ch9431 spi0.0: ----plink----spi->max_speed_hz: 12000000
[ 82.410237] ch9431 spi0.0: ----plink----spi->mode: 3
[ 82.465465] ch9431 spi0.0: ch9431_hw_probe, CH9431_CTRL 0x27
[ 82.465561] ch9431 device probe, driver version: V1.4.2 On 2026.04, fw version: V1.0.2a
[ 82.466114] ch9431 spi0.0: sysfs_create_group() and link ch9431-spi0-0 succeeded!
[ 82.466343] irq: IRQ397: trimming hierarchy from :bus@0:pmc@c800000
[ 82.467146] ch9431 spi0.0: Requested IRQ 397 for GPIO 534
[ 106.473273] ch9431 spi0.0: ch9431_do_set_bittiming, CNF: 0x04 0x00 0x00
[ 106.473506] ch9431 spi0.0: ch9431_do_set_bittiming, CNF: 0x04 0x00 0x00
[ 106.578080] ch9431 spi0.0: ch9431_set_normal_mode, ret = -110, ch9431 didn't enter in normal mode!
[ 106.578346] ch9431 spi0.0 can4: ch9431_open : ch9431 open failed, ret: -110
[ 106.580221] A link change request failed with some changes committed already. Interface can4 may have been left with an inconsistent configuration, please check.
When no patch is applied, the driver is registered probabilistically and after successful registration, the following situation will occur:
Cannot open the CAN device, Log as follows;
It is capable of sending CAN data, but the CAN analyzer is unable to receive the data.Can receive the data sent by the CAN analyzer normally.
Added more debugging information. At present, it is not clear whether the problem is with the unstable SPI communication or some other issue.
The corresponding GPIO has been configured.
What’s the meaning for this error in custom ch9431 driver?
I would strongly suggest using the LA or scope to check if the waveform of SPI is expected.
If the value read from the chip by SPI is incorrect, an error will be reported.
Subsequently, I will analyze the relevant waveforms for judgment. Currently, I am re-structuring the driver program. During the probe stage, only SPI device read and write operations will be performed. This test shows that the SPI communication is normal and the read values are correct. I will then re-design my driver program.
Do you mean the SPI work as expected and the current issue is caused from custom CH9431 driver?
Yes, please use LA or scope to check their waveform in the SPI loopback test to confirm if the SPI transaction works as expected.
Not sure. Because the driver has been verified to be normal on ORIN NX, and the corresponding interface functions of the driver are all supported by version 6.8.12. Currently, the only option is to gradually restructure the driver. There is no other better solution.
However, when comparing the waveforms, it was observed that the SCLK signal would turn into a continuous high level after the driver was loaded.
On Thor’s system
On the ORIN NX system.
Could you apply the following patch to check if it could help for your case?0001-spi-debug-SPI-issue-for-Thor-with-r38.4.patch (6.9 KB)
After applying this patch, it looks like the effect remains the same.
[ 472.660854] ch9431 spi0.0: ----plink----spi->max_speed_hz: 12000000
[ 472.660873] ch9431 spi0.0: ----plink----spi->mode: 3
[ 472.666111] spi-tegra114 810c590000.spi: msg: single xfer, cs_change=0 -> use_hw_cs=1
[ 472.666745] spi-tegra114 810c590000.spi: setup_xfer: using HW CS, cmd1=0x70400007
[ 472.666828] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 472.666831] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70400807
[ 472.688041] spi-tegra114 810c590000.spi: msg: multi xfer -> use_hw_cs=0 (SW CS required)
[ 472.688052] spi-tegra114 810c590000.spi: setup_xfer: using SW CS, cmd1=0x70600007 cs_high=0
[ 472.688096] spi-tegra114 810c590000.spi: xfer done: intermediate, cs_change=0, CS stays asserted
[ 472.688130] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 472.688132] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70401007
[ 472.692036] spi-tegra114 810c590000.spi: msg: multi xfer -> use_hw_cs=0 (SW CS required)
[ 472.692043] spi-tegra114 810c590000.spi: setup_xfer: using SW CS, cmd1=0x70600007 cs_high=0
[ 472.692074] spi-tegra114 810c590000.spi: xfer done: intermediate, cs_change=0, CS stays asserted
[ 472.692107] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 472.692109] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70401007
[ 472.720656] spi-tegra114 810c590000.spi: msg: multi xfer -> use_hw_cs=0 (SW CS required)
[ 472.720677] spi-tegra114 810c590000.spi: setup_xfer: using SW CS, cmd1=0x70600007 cs_high=0
[ 472.721038] spi-tegra114 810c590000.spi: xfer done: intermediate, cs_change=0, CS stays asserted
[ 472.721078] spi-tegra114 810c590000.spi: xfer done: last, cs_change=0, ending transfer
[ 472.721081] spi-tegra114 810c590000.spi: transfer_end: hw_cs=1 cs_val=1 cmd1=0x70401007
[ 472.721101] ch9431 spi0.0: ch9431_hw_probe, CH9431_CTRL 0x20
[ 472.721107] ch9431 spi0.0: Cannot initialize ch9431. Wrong wiring?
[ 472.721509] ch9431 spi0.0: ch9431_probe failed, err=19
dump_dmesg.txt (114.3 KB)
Could you also check if the patch from the following thread helps for your case?[R38.4] T4000/5000 SPI TPM issue - #13 by KevinFFF
After loading this patch, it seems that the driver can be loaded normally now.
When testing the CAN function, it was found that sometimes data could not be received, and the data sent was not all accepted by the CAN analyzer.
About dmesg：dump_dmesg_patch_20260525.txt (130.0 KB)
About Dts:dump_patch_20260525.zip (47.5 KB)
I don’t see the error in the dmesg you shared.
You can also simply run the following command to check the status of CAN.
$ sudo ip -d -s link show can4
nvidia@tegra-ubuntu:~/orin_nx_success/ch9431_linux_main_v1.4.2/driver$ sudo ip -d -s link show can4
13: can4: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE restart-ms 0
bitrate 500000 sample-point 0.875
tq 250 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1 brp 5
ch9431: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..256 brp_inc 1
clock 20000000
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 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0
RX: bytes packets errors dropped missed mcast
8 1 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
I don’t see there’s any error/dropped CAN data from the result you shared.
Please also check if the issue may be caused from CAN analyzer side.
