SPI Slave Communication Issue on Jetson Orin Nano (JP 6.1, L4T 36.4.0)

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
1

Hi @KevinFFF,

JetPack Version: 6.1
L4T Version: 36.4.0
Board: Custom Carrier Board
SOM: Jetson Orin Nano 4GB

We are working on configuring the Orin Nano as an SPI slave device to communicate with an external STM32 MCU acting as the SPI master. The MCU transmits 8 bytes of data (values 0 to 7), and we’ve verified via probing that the data is correctly transmitted on the SPI lines.

On the Orin Nano, we’re using a modified spidev application to capture 8-byte data packets. However, despite the Orin Nano being in listening mode (specifically in SPI modes 1 and 3), it does not capture any incoming data.

Upon reviewing the forums, we found discussions indicating potential issues with the SPI slave driver in the JetPack 6 series. Notably:

In the thread Cannot process SPI Slave Communication In JP 6.0 - #20 by bi.min, users reported that SPI slave communication worked in JP 5.1.3 but not in JP 6.0, even after applying similar configurations.

Could you please advise on the following:

  1. Are there any known fixes or patches for SPI slave communication issues in JP 6.1?

  2. Are there any specific configurations or modifications recommended for enabling SPI slave mode on the Orin Nano in JP 6.1?

We would appreciate your guidance on resolving this issue. If you require any additional information or logs, please let us know.

Thanks,

Pippalla Chakravarthi

3

Hi pippalla.chakravarthi,

Could you try use the spi slave driver from JP5.x to check if it could work with your use case?

Please share the full dmesg and device tree for further check before answering your questions.

5

Hi Kevin,

Thanks for your response.

Could you clarify whether we need to fully port the SPI slave driver from JP5.x, or if we can simply replace the driver and rebuild it on JP6.1? If there are specific dependencies to consider when using the JP5.x driver in JP6.1, please let us know.

dmesg_spi_slave_Driver_loads_first.txt (59.8 KB)
dmesg_spi_master_driver_loads_first.txt (60.1 KB)

spi_device_tree.txt (8.1 KB)
spi_devicetree_blob.txt (483.0 KB)

I have observed an inconsistent behavior regarding the SPI slave driver loading:

  • Scenario 1: When the SPI slave driver loads before the SPI master driver, the slave functionality operates on spi@3210000.
  • Scenario 2: Conversely, when the SPI master driver loads before the SPI slave driver, the slave functionality operates on spi@3230000.

However, in our device tree configuration, we have explicitly enabled the SPI slave mode only for spi@3230000. This inconsistent behavior is unexpected and raises concerns about potential driver or device tree configuration issues.

Could this be related to the driver loading sequence or perhaps an underlying configuration in the device tree? Any insights or recommendations to ensure consistent and correct SPI slave operation on spi@3230000 would be greatly appreciated.

6

It should be fine that you port SPI slave driver from JP5.x to JP6.x codebase and run the command to rebuild kernel image.

It is expected since the SPI number assigned depending on the order of driver loaded.

You can add them in aliases to prevent this issue.

I would suggest you disbling the spi@3210000 node as following if you just want to use spi@3230000 in your use case.

		spi@3210000{
-			status = "okay";
+			status = "disabled";