I followed all the relevant documentation and forum posts and created custom pin muxing for the Orin Nano DevKit. Since DevKits are not intended for production, we will eventually use a custom board designed in-house.
The current task is to prepare for the customizations required for our custom board.
Please note that tools like jetsion.io or devmem will only be used for verification and not as part of the customization process.
With the custom pin muxing, device trees, and custom board configuration, it appears they have been applied correctly based on the logs and the interfaces exposed in the Linux userspace.
Problem:
When I used spidev test code with loopback for spi3.0 (/dev/spidev2.0), the data I sent did not appear as expected. In the logic analyzer, I see the data on both MISO and MOSI lines, and the SCK and CS signals are toggled as expected. However, the data I read via spidev test is incorrect. It’s not clear what is missing or what I’m doing wrong.
I compared the pinmux configuration set in the tegra234-p3767-0000-common-hdr40.dtsi file. I noticed an odd configuration; for all SPI3 pins, nvidia,enable-input = <TEGRA_PIN_ENABLE>; is set, which doesn’t seem correct to me (though this might not be relevant to the issues I’m experiencing).
Any pointers regarding the issues I observe with SPI3.0 would be helpful. Thanks…
I will share relevant changes, logs, and screenshots if required, please let me know…
MISO and MOSI lines for both spi3 and spi1 are connected and then run the spidev_test :
Today, I retested the setup. Yesterday, I was using the RPi hat-rack, which extends the signals from the 40-pin header on the devkit, and I utilized header cables of approximately 20 cm in length. Today, I connected directly to the 40-pin header using shorter, ~10 cm header cables, and I was able to observe the looped data. This seems to indicate issues with drive strength.
I then attempted to interface with an IMU module for testing but encountered issues. The signals were all in the wrong states, leading to a failure in communication with the IMU. To ensure sanity, I tested the same code base and hardware on a different platform (not Nvidia), where everything worked as expected.
Is there anything specific I should set concerning signal drive strength?
Is you issue about the behavior of you CS not expected?
I would suggest you could compare the waveform when you are verifying with loopback test and communicate with IMU module.
Maybe you issue is coming from the spi mode?
What’s you driver using for IMU module? Is there any error in dmesg during probe?
Is you issue about the behavior of you CS not expected?
not only CS, but all signals.
I would suggest you could compare the waveform when you are verifying with loopback test and communicate with IMU module.
I did that and shared my observed waveforms in my previous response.
The first screenshot is when sending “Hello World” via the spidev test. The signals are decoded by logic analyzer without any issues.
The second screenshot is when running the IMU test application without connecting the sensor to the bus. The signals are decoded by logic analyzer without any issues.
The third screenshot is when running the IMU test application, connecting the sensor to the bus. Logic analyzer could not decode the signals properly.
Maybe you issue is coming from the spi mode?
I think the mode is not causing any issues. As I said, the same code base is verified on other platforms and confirmed that it works.
What’s you driver using for IMU module? Is there any error in dmesg during probe?
It is not a driver, it is a userspace application. It utilizes spidev interface to send and receive data over spi.
There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks
Is this still an issue to support? Any result can be shared?
