Hello! On Channel 0 we’ve got the chip select, and Channel 4 is the clock.
We are running SPI at 2Mhz, but there seems to be a 400us delay between the chip select falling and rising again for the next transaction. This drastically reduces our ability to run SPI at 2Mhz. We have run jetson clocks and are running this on a jetson nano devkit.
Is there a way to reduce this time? We are using gpio chip selects, would this be characteristic of that? Are there any settings in the device tree we can use? In the IOCTL spi transfer we have the delay_usec set to 0.
Any help will be greatly appreciated.
Sorry for the late response, our team will do the investigation and provide suggestions soon. Thanks
Looking into this. I will provide an update in few days
Can you share the dtb file ? is the hw cs property present in the device tree settings ?
device_tree.dts (330.5 KB)
here is the file we use
we don’t have hw cs property because we use cs-gpio
@va11 @kayccc any updates on this?
@akhil.veeraghanta can you try using hw based CS instead of CS gpio?
We have, but the reason we are using CS gpio is because we need that SPI interface to handle 5 devices. With the hw based CS we only get 2
Hey any updates on this? we still have this issue
Are you using the devkit or custom board for Jetson Nano?
Could you help using latest R32.7.3 with the following modification for CS to verify?
SPI TPM module support fail on jetpack 5.0.2/5.1 on jetson xavier agx - #25 by DaneLLL
You can try my library to handle the CS as gpio outputs and keep the rest of your code as it is to handle the SPI. I ran some tests and I am able to switch gpios as outputs in around 0.5 us. Check it out here if so: GitHub - Rubberazer/JETGPIO: C library to manage the Jetson Nano GPIO
I think this is probably the way to go, there is just something broken on the nano that doesn’t allow this to work
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.