Orin Nano SPI not working

I want to preface with saying I have used the spi ports on our custom carrier with a Jetson Nano with no problem. The board is designed to work with Jetson Nano, Jetson XavierNX and Jetson Orin Nano. All three boot with no problem.

I was attempting to use the same method to enable spidev0 and spidev2 as seen in dev once you boot up.

I used the jetson-io.py and created a new dtb file that enables the 40-pin header for both spi ports. I reboot and have to use

sudo modeprobe spidev

because the names written in are tegra-spidev and those don’t get automatically added (known issues others are seeing).

At this point, I do see /dev/spidev0.0 0.1 2.0 2.1 as I would expect.

I tried a loopback test and I do not see the value being received on 2.0 (which is the easiest to test on our board). This is verified by hooking up the Jetson Nano to the same hardware and running our test code which uses spidev1.0 with no problem.

This is Jetpack 5.1.2

I used to use this:

sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep -I spi

To check the status of the pins, but this is no longer in the debug directory.

I am uncertain of the addresses to check for both these spi ports. (using busy box devmem)

Not sure what else to try. My suspicion is for some reason, maybe the pins are not setup correctly. But I definitely am using the settings jetson-io wrote out and have verified the new DTB is being loaded.

Any pointers of what to look at next?

Thanks
Rick

Using:

cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinconf-groups

I see:

110 (spi3_miso_py1): 
	pull=1
	tristate=0
	enable-input=1
	open-drain=0
	io-reset=0
	rcv-sel=0
	io-hv=0
	loopback=0
	schmitt=0
	pull-down-strength=0
	pull-up-strength=0
	drive-type=0
	func=spi3
	pad-power=0
112 (spi3_cs0_py3): 
	pull=1
	tristate=0
	enable-input=1
	open-drain=0
	io-reset=0
	rcv-sel=0
	io-hv=0
	loopback=0
	schmitt=0
	pull-down-strength=0
	pull-up-strength=0
	drive-type=0
	func=spi3
	pad-power=0
114 (spi3_cs1_py4): 
	pull=1
	tristate=0
	enable-input=1
	open-drain=0
	io-reset=0
	rcv-sel=0
	io-hv=0
	loopback=0
	schmitt=0
	pull-down-strength=0
	pull-up-strength=0
	drive-type=0
	func=spi3
	pad-power=0
116 (spi3_sck_py0): 
	pull=1
	tristate=0
	enable-input=1
	open-drain=0
	io-reset=0
	rcv-sel=0
	io-hv=0
	loopback=0
	schmitt=1
	pull-down-strength=0
	pull-up-strength=0
	drive-type=0
	func=spi3
	pad-power=0
119 (spi3_mosi_py2): 
	pull=1
	tristate=0
	enable-input=1
	open-drain=0
	io-reset=0
	rcv-sel=0
	io-hv=0
	loopback=0
	schmitt=0
	pull-down-strength=0
	pull-up-strength=0
	drive-type=0
	func=spi3
	pad-power=0

Going through the TRM, checking to make sure the above data is correct, I see:

busybox devmem 0x0243d000 SPI3_MISO = 0x00000444
busybox devmem 0x0243d048 SPI3_MOSI = 0x00000444
busybox devmem 0x0243d030 SPI3_SCK = 0x00001444
busybox devmem 0x0243d010 SPI3_CS0 = 0x00000444

Which seems to follow recommendations in other posts. (Unless I have misunderstood). Given I am doing just a loopback test shorting MISO to MOSI, I don’t even think in that case I care about SCK and CS0 for this test.

The only thing I am curious about is “pad-power” is that something that is just used for GPIO purposes?

Do you mean that you use the same custom carrier board for Jetson Nano, Xavier NX and Orin Nano?

For my understanding, they are from different platform and there should be differences on the carrier board.

Jetson-IO should only work with the devkit.
Do you have Orin Nano devkit could verify the SPI loopback test?

I’ve gone extensively through the documention on all three boards and have gone through all the differences that are detailed in the guide documents that are supplied in the downloadable material. There are very minor differences in the SoM outputs and I have designed so that none of those differences affect my usage of all three SoM on my custom carrier.

That said, while the carrier boards can support different things, the custom board was designed specifically to the needs of The Orin in terms of power. Like I said, the Orin boots no problem on it and we have HDMI working on it through the help of Wayne. USB3 works. I have not tested I2S yet.

In this specific case, I checked the SOM pinout of each carrier and can confirm, the SPI ports come out the same pins. The difference being, Jetson Nano used SPI1 and SPI2 whereas Orin used SPI1 and SPI3, but, SPI3 is what is used on the same pins on the Jetson IO. Jetson IO correctly enables SPI3 instead on the Orin SoM.

I used the Jetson-IO tool on the Jetson Nano to enable the SPI ports on my custom carrier and there is no reason that shouldn’t work with the Orin as well. To the SoM, my usage of the pinmux settings are going to be the same. I verified that the pinctrl settings look to be correct as much as other people are seeing.

I do have an Orin Nano devkit, that is a good idea. I will do a loopback test on there as well to see what happens with the same image.

@KevinFFF, I discovered the problem, but I am not sure how to fix it.

I dropped the SPI frequency from 60Mhz to 40Mhz and now it works. On the Jetson Nano, I can drive with 60Mhz with no problem. I walked down by 10Mhz at a time to see what would work (after seeing signals on the scope).

Is there something different I need to do on the Orin to get the same quality signal? Like is this some sort of drive issue? Maybe the SPI port is not setup exactly correct here?

Could you refer to the following thread to use different parent clock for SPI working with lower frequency?
Can not config the SPI2's CLK frequency - #9 by KevinFFF

I will try this and let you know, thanks!

Didn’t seem to make a difference. Must be some subtle difference in the output side of the circuitry. I tried different sources and then checked the speed which matched my request, and it was correct.

Could be the problem is really with the LCD driver chip and I just got lucky on the Jetson Nano and Ri3B compute modules. I am pushing it harder than their guarantee of performance. That said, I have about 600 units in the field running no problem at 60Mhz. Since there are other parts of the system that need my attention I will come back to this and try and dig in further. (Since I could scope up the Jetson Nano and Orin Nano and see the difference in waveforms.

What difference in waveforms do you see for Jetson Nano and Orin Nano?

I haven’t had a chance to bring back up the Jetson Nano on this custom carrier yet, but now that I am having trouble with a different spi device with tricky read timing that worked no problem on the Jetson Nano. This is leading me to believe the tx/rx tap delay must not be working properly. I’ve started a discussion on this on another page and plan to utilize my scope Monday to dig deeper.

okay, let’s just discuss on another topic you just created

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