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

[pippalla.chakravarthi]

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

[KevinFFF]

Hi pippalla.chakravarthi,

@pippalla.chakravarthi

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 try use the spi slave driver from JP5.x to check if it could work with your use case?

@pippalla.chakravarthi

If you require any additional information or logs, please let us know.

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

[pippalla.chakravarthi]

Hi Kevin,

Thanks for your response.

@KevinFFF

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

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.

@KevinFFF

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

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.

[KevinFFF]

@pippalla.chakravarthi

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?

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.

@pippalla.chakravarthi

• 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.

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

@pippalla.chakravarthi

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.

You can add them in aliases to prevent this issue.

@pippalla.chakravarthi

we have explicitly enabled the SPI slave mode only for spi@3230000

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";

[pippalla.chakravarthi]

Just wanted to check if I’m on the right track here. I’m trying to get SPI working with Orin Nano as the SPI slave and an MCU as the master.
Here’s what I’ve done so far:

1. Updated the device tree—changed the SPI node’s compatible string from:

compatible = “nvidia,tegra210-spi”, “nvidia,tegra114-spi”;

to:

compatible = “nvidia,tegra210-spi-slave”, “nvidia,tegra114-spi-slave”;

2. After the change, the spidev driver loads fine for the modified SPI node.

3. I’m using spidev_test.c to try and read incoming data. The executable runs and waits for input, but it seems like the Orin Nano isn’t sampling anything at all. No signs of activity on the slave side.

So now I’m wondering — could this be some kind of clock sync issue? Maybe the slave isn’t seeing the clock from the master, or there’s a mismatch in timing?

[KevinFFF]

@pippalla.chakravarthi

compatible = “nvidia,tegra210-spi-slave”, “nvidia,tegra114-spi-slave”;

It is the expected modification to configure SPI slave.
Please just modify it for spi@3230000 and disable the node for spi@3210000.

@pippalla.chakravarthi

I’m using spidev_test.c to try and read incoming data. The executable runs and waits for input, but it seems like the Orin Nano isn’t sampling anything at all. No signs of activity on the slave side.

Please provide the full dmesg and device tree when you hit this issue.
And share the block diagram of your connection with MCU.

[pippalla.chakravarthi]

Hello @KevinFFF,

@KevinFFF

Please just modify it for spi@3210000 and disable the node for spi@3210000.

We actually need both SPI nodes enabled for our use case.

Just an update: we’ve made good progress on configuring SPI in slave mode. I discovered that for SPI slave to work properly, the following pinmux change is required:

nvidia,enable-input = <TEGRA_PIN_DISABLE>; → nvidia,enable-input = <TEGRA_PIN_ENABLE>;

After applying this change, we are now able to receive data from the master. However, the received data is mismatched/corrupted — it’s not coming through correctly.

From the master side, we are sending the following 8-byte pattern:

While we occasionally receive the correct pattern, most of the runs result in corrupted data. We’re using a slightly modified version of the spidev_test tool to receive 8 bytes of data.

I’m attaching the dmesg logs and application prints for reference.
SPI_slave_logs_App.zip (20.6 KB)

Could you please help us understand what might be causing the data corruption? Any insights on resolving this at the earliest would be greatly appreciated.

[KevinFFF]

@pippalla.chakravarthi

Just an update: we’ve made good progress on configuring SPI in slave mode. I discovered that for SPI slave to work properly, the following pinmux change is required:

nvidia,enable-input = <TEGRA_PIN_DISABLE>; → nvidia,enable-input = <TEGRA_PIN_ENABLE>;

You can also refer to Jetson Sensor Processing Engine (SPE) Developer Guide: SPI application (app/spi-app.c and app/spi-slv-app.c) for pinmux configurations of SPI Slave

@pippalla.chakravarthi

Could you try sending the data with hex instead?

[  365.184186] 01 
[  365.184189] 55 
[  365.184190] 02 
[  365.184190] 03 
[  365.184191] ff 
[  365.184192] ff 
[  365.184193] 40 
[  365.184193] 00 

Where do you print theses data?

Do you also scope or logic analyzer to check if there’re expected data on SPI bus?