Hi,
I’m using adis16470 to get motion data by compiling adis_lib and adis16475 to .ko and modprobe them into kernel. It seems that spi is not working properly.
Source code is from BSP 36.4.3 and Linux is 5.15.185
nvidia@ubuntu:/sys/bus/iio/devices/iio:device0$ sudo dmesg | grep spi
[ 10.622964] spi-tegra114 3210000.spi: Adding to iommu group 1
[ 10.654568] spi-tegra114 3230000.spi: Adding to iommu group 1
[ 11.330151] adis16475 spi0.0: Device ID(16470) and product ID(0) do not match.
By using logic analyzer,
The cs always act weired:
External Media
Willing to get your response to solve this issue.
after add patch to
still got error on my jetson (jetpack 6.2.2)
[ 1033.042378] adis16475 spi0.0: Data Path Overrun.
[ 1033.042392] adis16475 spi0.0: Flash memory update failure.
[ 1033.042397] adis16475 spi0.0: SPI communication error.
[ 1033.042402] adis16475 spi0.0: Standby mode.
[ 1033.042406] adis16475 spi0.0: Sensor failure.
[ 1033.042411] adis16475 spi0.0: Memory failure.
[ 1033.042415] adis16475 spi0.0: Clock error.
[ 1033.042422] adis16475: probe of spi0.0 failed with error -5
When do execute modprobe adis16475, I got:
Seems the cs got something wrong.
Hi,
You may not enable the interface in device tree correctly. Please check which interface is connected and modify device tree. For more examples, please refer to
Making sure you're not a bot!
This is my Overlay dts, I set the SPI function by sudo /opt/nvidia/jetson-io/jetson-io.py
And passed the spi-loop test. Can you help check if any issue in here?
/dts-v1/;
/plugin/;
/ {
compatible = "nvidia,p3768-0000+p3767-0000", "nvidia,p3767-0000", "nvidia,tegra234";
fragment@0 {
target-path = "/bus@0/spi@3210000";
__overlay__ {
status = "okay";
};
};
fragment@1 {
target-path = "/bus@0/spi@3210000/spi@0";
__overlay__ {
status = "disabled";
};
};
fragment@2 {
target-path = "/bus@0/spi@3210000/spi@1";
__overlay__ {
status = "disabled";
};
};
fragment@3 {
target-path = "/bus@0/spi@3210000";
__overlay__ {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
imu@0 {
status = "okay";
compatible = "adi,adis16470";
reg = <0>;
spi-max-frequency = <2000000>;
spi-cpha;
spi-cpol;
interrupts = <118 1>;
interrupt-parent = <&gpio>;
adi,sync-mode = <0x00>;
controller-data {
nvidia,enable-hw-based-cs;
nvidia,rx-clk-tap-delay = <0x11>;
nvidia,tx-clk-tap-delay = <0x0>;
};
};
};
};
};
OVERLAYS /boot/jetson-io-hdr40-user-custom.dtbo,/boot/adis16470_overlay_2.dtbo
I have noted that nvidia,enable-hw-based-cs; may be a issue, and I tried to remove from my dts but helps nothing.
Hi,
Would suggest use Jetpack 6.2.2 r36.5.
On r36.4.3, please apply the patches for a try:
Making sure you're not a bot!
[GPIO] Fix bit 10(SFIO) been set by gpiod
[SPI] SPI2 DMA transaction failed issue
Currently using jetpack 6.2.2 with r 36.5, spi-tegra114.patch applied, the same issue.
Updates:After E8 80 E9 00 00 00 02 00 00 00, the next 72 00 , should return 40 56(16470) but no data on bus.
For ADIS16470, I used the driver from BSP source, now I can read back the product ID, but after this, it does not as expected by DR burst mod, but as shown below:
HI Dane,
I’m now able to read data from IMU16470, but when I follow the steps from ADIS16475 driver — The Linux Kernel documentation to set buffer, I got no output from hexdump, this is my newest dts. Can you help to identify which part is not correct?
adis16470_overlay.txt (1.4 KB)
Hi lgc_tst,
For the CS related issue, please check if the patch from the following thread could help for your case.
Jetson orin nano SPI Speed not changing - #9 by KevinFFF
Hi Kevin,
I have solved the scs issue and can read data by using cat in_xxxxx_, but when I follow the instruction by: ADIS16475 driver — The Linux Kernel documentation to trigger burst mode, 16470 give wrong data, something like:
00023570 13 00 e1 0c 88 ff b2 18 00 00 00 00 00 00 00 00 |…|
00023580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
00023590 00 00 00 00 00 00 00 00 04 a7 ea 0c 88 ff b2 18 |…|
000235a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
*
000235c0 b2 77 f2 0c 88 ff b2 18 00 00 00 00 00 00 00 00 |.w…|
000235d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
000235e0 00 00 00 00 00 00 00 00 4e ad 01 0d 88 ff b2 18 |…N…|
000235f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
*
00023610 84 f6 0d 0d 88 ff b2 18 00 00 00 00 00 00 00 00 |…|
00023620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
00023630 00 00 00 00 00 00 00 00 d7 44 18 0d 88 ff b2 18 |…D…|
00023640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
Usage examples
Set device trigger in current_trigger, if not already set:
root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
root:/sys/bus/iio/devices/iio:device0> echo adis16505-2-dev0 > trigger/current_trigger
root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
adis16505-2-dev0
Select channels for buffer read:
root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_x_en
root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_y_en
root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_z_en
root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_temp0_en
Set the number of samples to be stored in the buffer:
root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length
Enable buffer readings:
root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
Obtain buffered data:
root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0
...
00001680 01 1f 00 00 ff ff fe ef 00 00 47 bf 00 03 35 55 |..........G...5U|
00001690 01 1f 00 00 ff ff ff d9 00 00 46 f1 00 03 35 35 |..........F...55|
000016a0 01 1f 00 00 ff ff fe fc 00 00 46 cb 00 03 35 7b |..........F...5{|
000016b0 01 1f 00 00 ff ff fe 41 00 00 47 0d 00 03 35 8b |.......A..G...5.|
000016c0 01 1f 00 00 ff ff fe 37 00 00 46 b4 00 03 35 90 |.......7..F...5.|
000016d0 01 1d 00 00 ff ff fe 5a 00 00 45 d7 00 03 36 08 |.......Z..E...6.|
000016e0 01 1b 00 00 ff ff fe fb 00 00 45 e7 00 03 36 60 |..........E...6`|
000016f0 01 1a 00 00 ff ff ff 17 00 00 46 bc 00 03 36 de |..........F...6.|
00001700 01 1a 00 00 ff ff fe 59 00 00 46 d7 00 03 37 b8 |.......Y..F...7.|
00001710 01 1a 00 00 ff ff fe ae 00 00 46 95 00 03 37 ba |..........F...7.|
00001720 01 1a 00 00 ff ff fe c5 00 00 46 63 00 03 37 9f |..........Fc..7.|
00001730 01 1a 00 00 ff ff fe 55 00 00 46 89 00 03 37 c1 |.......U..F...7.|
00001740 01 1a 00 00 ff ff fe 31 00 00 46 aa 00 03 37 f7 |.......1..F...7.|
...
See Documentation/iio/iio_devbuf.rst for more information about how buffered data is structured.
Can you help with the issue?
What was the root cause of the previous issue?
Did the patch I provided resolve the problem?
Sorry that we don’t have this module to verify ADIS16470 locally.
If the issue is specific to ADIS16475 driver, please also request your vendor for the help.