Jetson Nano SPI configuration


I have a Jetson module with a02 board. I have installed L4T by following Nvidia’s Getting Started Guide. (JetPack 4.5.1)

I need to use SPI to communicate with Decawave DWM1001DevKit, so I enabled SPI via jetson-io utility Nvidia provided.

Decawave provided an API C code with examples (originally developed for Raspberry Pi 3). Its hardvare abstraction layer uses spidev with IOCTL transfers so I guess it should work also on Jetson Nano after configurated SPI driver properly.

I tested Decawave provided API example code with a Raspberry Pi 4. It worked, and I used a logic analyser to record the first 6 secs of the communication between RPi 4 and DWM. After that I recorded the communication between the Nano and the DWM to be able to compare.

My conclusion is that CS pin sometimes stays active for extra 1-2ms (or until next message) after a message sent.

This is a printscreen of the communication between Nano and DWM

This is a printscreen of the communication between RPi4 and DWM

Another observation is that there is no time between 2 byte sent after each other. CLK is continous for 16 cycles.

This is a printscreen of the communication between Nano and DWM

This is a printscreen of the communication between RPi4 and DWM

Later I realized, that this L4T image is not specially for my setup, because it is for b01 or b02 board, but it contained a *a02.dtb file, so I managed the operating system to boot with that dtb. But unfortunately it did not affected anything.

Any help would be appriciated!

Need take time to check this with developer, however current resource is tight due to COVID-19 may response slowly.


I’m also checking.

Can you share the code you’re using to test with? Is it using read()/write() or the SPI_IOC_MESSAGE ioctl?

Does “sometimes” mean if you repeat the same test under the same conditions, sometimes CS is correct and sometimes it stays active the extra time? Is there another SPI device other than the Decawave connected to those pins?

I think I’ve seen that one before. I have to find some code I wrote a few years ago when I was testing SPI initially. I also made some driver and DTB fixes so I’ve got to find those as well.

These are the hardware abstraction layer spi codes. It uses SPI_IOC_MESSAGE.

hal_spi.c (7.2 KB)
hal_spi.h (1.7 KB)

“sometimes” means that I can not realise a pattern by observing at which message does it stay active too long, but it behaves the same at same conditions and same test program.

UPDATE: I sat the CLK frequency to 800kHz to see what will change. Then communication worked. After that I increased the frequency. The maximum acceptable freq is 1.2MHz. By observing the signals at this freq there is no time between 2 bytes either (so this is not a real problem in this case), but CS signal does the same random thing, but now it is not so long, so slave can interpret messages and can answer.

I would be grateful if you could find those fixes for me.

Yep, sorry about that. I’ll try to find them today.

So JetPack 4.6 / L4T 32.6.1 was just released this week and it does have a bunch of chip select changes in the SPI driver. Can you try upgrading to that kernel?

Sorry for getting back to you lately. What is the fastest and most secure way to upgrade to the new kernel? I mean I want to backup this checkpoint if something goes wrong by upgrading. For this, my only plan is to make an image of tha SD card that I can reflash at any time. And regarding to the upgrade my only idea is to download the new OS and flash it to the SD card. Any better idea?

I’d suggest to start from scratch with a new sdcard using the latest JetPack/L4T and see if it solves your issue. If not, there’s no point in going through the upgrade process. If it does solve your issue, I can give you simple instructions to clone your existing sdcard and update it to the new kernel.

1 Like