I attempted to apply the suggested kernel patch for the sfsel bit fix. I also modified the DTB to set SPI3 (3230000.spi) as slave mode and successfully ran the single loopback test on spidev1.0 (master). However when attempting the SPI master/slave test between the two SPI buses, something went wrong — after reboot the WiFi was missing and the kernel was not working properly. I ended up reflashing JP6.2.1 fresh( before that i was working on jp6.2.
What I want to do now (starting fresh):
I want to use SPI1 as master to communicate with an LSM6DSO IMU sensor. Before doing anything I want to make sure I do it correctly this time.
Specifically I need help with:
Should I apply the sfsel kernel patch first? If yes, what is the safest way to do it on JP6.2.1?
Do I need to modify the DTB for SPI master mode to work with an external SPI device, or is SPI1 master ready to use out of the box?
Is there a recommended Python or C example for reading LSM6DSO data over SPI on Jetson?
I want to do this step by step without breaking anything. Any guidance is appreciated!
i also performed a loop test (connecting pin 19 to pin 21 ) by the following method :
sudo modprobe spidev
git clone GitHub - rm-hull/spidev-test · GitHub
cd spidev-test/
gcc spidev_test.c -o spidev_test
Run the test program and specify spidev0.0 (corresponding to SPI1):
./spidev_test -v -D /dev/spidev0.0 -p “Test”
and got this :sdp_ab@sdp:~/spidev-test$ ./spidev_test -v -D /dev/spidev0.0 -p “Test”
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | 54 65 73 74 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | Test
RX | 54 65 73 74 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | Test
Have you also updated the OOT kernel modules correctly?
This patch is used to fix the SFIO bit been set issue when you want to use the pin as GPIO.
It seems not relating to your current requirement to port LSM6DSO IMU on SPI bus.
You have to configure its pinmux first. For the devkit, you can simply use the jetson-io tool to enable SPI.
You need to get the sample code/application from your vendor to work with LSM6DSO.
We could help to verify SPI loopback test for the the SPI functionality.
sorry i didnt understant this one
but the same lsm6ds3( sorry i typed the wrong name lsm6ds3 is the one iam using ) worked fine with the spi using esp and also its working right now with the i2c but not responding with the spi and retureing oxff
For your lsm6ds3 module, you may need to use the drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c driver. Since this is not the module devloped from us, we do not have the hardware to perform local verification. We recommend requesting further technical details from your vendor.
Thanks for your response, actually I buy it from a Chinese market so it’s kinda hard to get this information.
1-shouldnt be this available on the internet?
2-is there any official guide to how to update the device tree to use a coustem driver ?
Also iam using lsm6ds3 not lsm6dso
Not that I also used rc522 card reader on spi and it worked fine so either the problem be the level shifter or a software based if you can help me Mr Kevin iam close to my deadline of the project
It seems this driver exists in upstream kernel by default.
You may ask the vendor for the required Device Tree configurations for the st_lsm6dsx_spi.ko driver.
I can help identify the specific Device Tree files on the Orin Nano that need updating.
I applied a DT overlay via eMMC partition patching with:
compatible = "st,lsm6ds3";
reg = <0x0>;
spi-max-frequency = <1000000>;
spi-cpol;
spi-cpha;
Plus Tegra controller-data (nvidia,enable-hw-based-cs, nvidia,rx-clk-tap-delay).
Result: The driver probed and bound to spi0.0 correctly, but reads WHO_AM_I = 0x00 instead of the expected 0x69.
I also did a raw SPI test using spidev with all 4 SPI modes and speeds from 100 kHz to 10 MHz — every single read returns 0xFF. This confirms the IMU is not responding at all on MISO.
Note that SPI loopback works, and RFID-RC522 works on the same SPI bus at 10 MHz. The LSM6DS3 also works fine over I2C on this same Jetson. So the IMU hardware is not broken.
The TXB0108 has weak output drivers (~4kΩ) which cannot overcome the Jetson’s internal pull-down on MISO. The RC522 works because it has much stronger MISO output drivers (~20mA) than the LSM6DS3 (~4mA).
My question: Is there a known hardware workaround for this on the Orin Nano, or is using I2C the recommended path for SPI devices with weak MISO drive strength?