Jetson orin nano SPI Speed not changing

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
1

Hi I am working on jetson orin nano and trying to use the spi peripheral. I have observed that when I change the speed of SPI clock it does not change. As suggested I did the spidev_test with spi1.1. For loop back my MISO (Pin22) and MOSI (Pin 37) are shorted. My SCLK(Pin13) is connected to oscilloscope for observation. I ran couple of test with clock speed change to 5000khz, 500kHz and 1000kHz. With 5000kHz the clock speed changes to around 4.96Mhz but for the rest it remain same as 3.182Mhz. As require I am attaching dmseg, .conf, dtb and command I ran.
spi_dmseg_log.txt (61.4 KB)
extlinuxAnddtb.zip (41.2 KB)

terminal_commands.txt (1010 Bytes)

Problem seems similar to this

Thanks a lot.

3

Hi nauman2,

Are you using the devkit or custom board for Orin Nano?
What’s the Jetpack version in use? (JP6.1-R36.4.0?)

I’ve checked the device tree shared from you as following.

                spi@3230000 {
                        compatible = "nvidia,tegra210-spi", "nvidia,tegra114-spi";
                        reg = <0x0 0x3230000 0x0 0x1000>;
                        interrupts = <0x0 0x26 0x4>;
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;
                        clocks = <0x3 0x89>;
                        clock-names = "spi";
                        iommus = <0x4 0x4>;
                        assigned-clocks = <0x3 0x89>;
                        assigned-clock-parents = <0x3 0x66>;
                        resets = <0x3 0x5d>;
                        reset-names = "spi";
                        dmas = <0xed 0x11 0xed 0x11>;
                        dma-names = "rx", "tx";
                        dma-coherent;
                        status = "okay";

May I know what’s your use case?
Do you want to run SPI with lower clock frequency like 500kHz or 1000kHz?

Have you also verified with JP5.1.4(R35.6.0)?

4

Hi I am using 36.4.0-20240912212859. I am doing initial testing of some SPI device such as DRAM CLICK. I would like to run them as fast as possible. But right now DRAM Click does not respond to command sent by jetson orin nano. I know about the jetson orin nano developer kit drive strength problem so I was willing to start with 1Mhz or even slower if needed just to confirm that it works with jetson orin nano. Same DRAM Click boards works well with ESP32 so the board is fine and working.
I have not tried JP5.1.4 yet. Would you recommend to shift to it? Also how did you extract the dts file from dtb because when i do it here it shows some error in extraction? I also installed JetGPIO library but for some reason after installing it jetson-io.py does not run and i later on uninstalled it. Could it be reason for SPI problem?
By the way I am using jetson orin nano 8GB developer kit.

5

Both JP6.1 and JP5.1.4 are the latest release. You can also verify with JP5.1.4 to compare if there’s any difference in your case if you don’t have the requirement for JP6.

I just run the command like the following.

$ dtc -I dtb -O dts -o extracted.dts kernel_tegra234-p3768-0000+p3767-0005-nv.dtb

It should be fine to use them if you are using the Orin Nano devkit.

Could you share the block diagram of your connections with DRAM CLICK?

6

Hi, I have an extra SD card of 64GB. So I installed jetpack 5.1.4 in it and with that after testing I can confirm that the speed of spi clock now changes. So the issue is may be specific to jetpack 6.1.
I also followed and tried the command you mentioned for dts. And as I said when i run it I see couple of warnings on terminal. I have attached the warnings here
dtc_warnings.txt (66.9 KB)
I am interested in these because few days ago I was looking to change the I2C pins to GPIO, I extracted the file DTS file like this with warnings. I ignored the warnings and made the suggested changes in DTS file and recompile it. But the dtb file did not work and my board did not boot up after that. Finally i have to flash the new image using SDK manager.
About the JETGPIO library, I get the same error in 5.1.4. After installing it my jetson-io.py no longer works. When you try to run it shows on the screen for just a second and than disappear. It again starts working when I uninstall jetgpio library.
Please see the connections of DRAM Click Board and Jetson orin nano 40 pin header below:
DRAM Click Jetson(40 pin header pin)
SDI <====> MOSI(37)
SDO <====> MISO(22)
SCK <====> SCL(13)
CS <====> CS(16)
GND <====> GND(6)
3.3V <====> 3.3V(1)
This board works well with ESP32 controller I have but I have failed to acquire any response from it when running with SPI of Jetson orin nano. I have compared the waveform generated by Jetson orin nano and esp32 for SCLK and MOSI. They both matched for the naked eye. But for some reason DRAM CLICK does not respond to command from Jetson orin nano but recognizes the same command from ESP32. Any idea or suggestion what could be the reason?

7

Yes, there’s a function -set_best_clk_source() has been removed in JP6.
Could you just verify with JP5.1.4 for your use case?

Those warning should be fine and they can be ignored.

Maybe you should look into the signal to find the difference like the clock frequency/signal level/timing.

8

Hi, I looked at the signal on oscilloscope and the signal from orin nano to DRAM CLICK and signal from ESP32 to DRAM Click are same but still DRAM_CLICK response to ESP32 but does not response to Jetson Orin nano commands. Q1) I was thinking it may be related to CS control. Any idea how I can control the CS pin manually right now it is control by SPIDEV driver? Q2) I have tried JETGPIO library to control the additional GPIO pin as CS but using the JETGPIO library with SPIDEV driver results in Segmentation error whose reason is currently beyond my understanding. C program for SPIDEV library and JETGPIO library works fine when they are run separately. Q3) Jetson orin nano developer kit carrier board has TXB0108 bi directional level shifter. I have read that it causes problem in spi communication and may be the reason for device not working. I was looking at pinmux sheet of jetson orin nano and its spi pins has 3.3V Tolerance Enable options disable. If I enable it does it mean that spi pins from jetson orin nano now provides and accepts 3.3V and I no longer need level shifter? Am I correct in assuming this? Q4) if I need to change the setup and hold time for spi. Can I do it? Is it possible to achieve this using device tree overlay? Any example?

9

Is the CS pin working not as expected?
If not, please apply the following patch to check if it could help in your case.

diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -870,6 +870,8 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device *spi,
 			else
 				command1 &= ~SPI_CS_SW_VAL;
 		}
+		tspi->use_hw_based_cs = true;
+		command1 &= ~(SPI_CS_SW_HW | SPI_CS_SW_VAL);
 
 		if (!tspi->prod_list) {
 			if (tspi->last_used_cs != spi->chip_select) {
10

Hi, where will i find this file is it on host computer? I installed 5.1.4 using sdk manager do I need to download and setup the source files to make this changes? I was comparing the spi signal generated by ESP32 that are accpeted by DRAM CLICK board and SPI signals generated by Jetson orin nano. Has per my observation jetson orin nano some times leaves the MOSI signal to the last bit states which may not be an issue. Secondly In esp32 after every 1 bytes (8 Clock) there is an approximate delay of 2 Clocks. There is no such delay in Jetson orin nano. Is it possible to include this delay in spi transfer by updating the device tree?

11

Please refer to Kernel Customization — NVIDIA Jetson Linux Developer Guide 1 documentation to download the kernel source and you would find the source of SPI driver.

You may customize the SPI driver for your use case like adding some delays.

12

Hi, Thank you for the reply. I have seen the kernel customization document. But I have not been able to understand it completely. I get confuse about the location of file. Nevertheless about the SPI problem I checked the signal values with Oscilloscope and found out that with development board when MOSI output HIGH signal does not reach 3.3V and with CS pin when it pull low it does not reach 0 V. So I used a pull up resistor on MOSI and pull down resistor on CS. Now the communication works as per expectation.

13

The SPI driver(spi-tegra114.c) is included in kernel source.
Please let us know if you still have issue about using SPI.

14

Hi, Thank you for your reply. Right now I am not able to run the SPI clock above 20Mhz. Above 20Mhz communication between DRAM Click and Jetson orin nano fails. As per my understanding I should be able to run the Jetson orin nano up to 65Mhz. Is this limitation due to driver IC or is there any thing in the Spi driver that I need to check?

15

It may be relating to the parent clock in use.

Please share the result of the following commands on your board.

$ sudo su
# cd /sys/kernel/debug/bpmp/debug/clk/spi1
# cat parent
# cat rate
# cat max_rate
# cat possible_parents

Please also refer to set_best_clk_source() in SPI driver.

16

Kindly see the result of the command below:
root@desktop:/sys/kernel/debug/bpmp/debug/clk/spi2# cat parent
pllp_out0
root@desktop:/sys/kernel/debug/bpmp/debug/clk/spi2# cat rate
81600000
root@desktop:/sys/kernel/debug/bpmp/debug/clk/spi2# cat max_rate
81600000
root@desktop:/sys/kernel/debug/bpmp/debug/clk/spi2# cat possible_parents
pllp_out0 pll_c pll_aon clk_32k osc .
I think the clock is fine and should not be the cause of this behavior. Let me know what do you think?
" Please also refer to set_best_clk_source() in SPI driver." This i think i need to check on the host side, correct? I am still working on my understanding of source file on host.

18

Could you also verify SPI loopback test with more than 20MHz?

It is a function available in JP5.x but we removed from JP6.x.
You can just verify with JP5.1.4(R35.6.0) to check if it could work.

20

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