We have been using both SPI busses successfully with a custom daughterboard for months, but they are suddenly no longer working. Both SPI devices are listed in the device tree, and calls to use them don’t error out, they just give null bytes back regardless of what we do. Running the jetson-io.py utility shows that these pins are being used for SPI. Probing the pins on the header shows the CS line never falling and no activity on any of the others.
Hi,
It sounds like there is damage in hardware. Is it possible to re-flash the system and see if it works? If the software image is refreshed and the issue is still present, it is likely to be an issue in hardware.
We are going to attempt a re-flash today, but we’ve tried to rule out a hardware issue. It occurs on both SPI busses identically, the CS lines all pull high successfully, they just never pull low to initiate the SPI transaction. Additionally, using the Python GPIO library, we’ve been able to set and read all those pins successfully without issue, it’s just SPI that’s affected as far as we can tell.
We attempted a reflash, and SPI transactions still fail with a loopback test, but standard GPIO functionality is on all those pins functions correctly. If it is a hardware error, why would just the SPI controllers fail?
Hi,
Or please try this first and see if it works:
How to set gpio for spi? - #27 by DaneLLL
See if it work by connecting MOSI to MISO and can execute spidev_test to receive the data.
Re-flashing did not fix the issue, spidev_test only returns errors. Is there something that would cause just the SPI controllers on the SoC to fail but not the GPIO nor the rest of the chip?
I am also facing same issue. I am using spidev 1.1. It was working fine previously but with latest image I am not able to communicate with the adc device.
Hi,
If spidev_test fails, it may be something wrong in device tree, please help inspect the device tree and make sure the system is re-flashed with the new dtb file. We have seen certain issues when only kernel partition is updated. It is suggested in Jetson Nano FAQ
Q: Why pinmux setting does not work on some pins?
As far as we can tell, all SPI busses are present in the .dts file when we extract the device tree. What would we be looking for if the issue was there?
Hi,
It seems like the board may be damaged. Another use has tried the same and it runs successfully:
Jetson nano Spi not working - #4 by abhi_developer
Are you able to try previous Jetpack 4.6 or 4.6.1? See if it works in either release.
We’ve accepted that the module itself may be damaged, but we’re wondering what would cause the damage specifically to the SPI controller in order to prevent this in the future. All other SFIO works, as does manually changing the pins with GPIO. Only SPI is affected.
We have tested with a new Jetson Nano. A fresh install SD card passed Spidev test. We then used the working SD card we’ve been using for months. This failed Spidev test and now the fresh install does as well. We are at a loss at how a software change could affect the SPI controller. I know that the Jetson has some configuration info stored in the QSPI flash chip on the module. Could this be the culprit in any way?
It could be ESD damage.
Hi,
If the modules are still in warranty, you may consider do RMA:
https://developer.nvidia.com/embedded/faq#rma-process
We’ve “fixed” the issue we think, as we now have two modules with recovered SPI functionality. Our best theory is that after running an update on our development SD card that something changed in the bootloader update payload that upon reboot, killed SPI functionality on that module. We used the SDK manager and forced recovery mode to completely roll back each module to 4.6.2. This restored SPI functionality. Afterwards, using the development SD again on these modules caused the bootloader to update and broke SPI functionality again. We’re migrating code slowly, but we’re fairly confident that its an issue with the bootloader and fixed by rolling that back.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.