How Access spi on torizon using python

I am using torizon imx7d for running spi in python but i am getting fixed value
I did steps:
1)when i run # docker run --rm -it -v /dev:/dev --device-cgroup-rule=‘c 254:* rmw’ torizonextras/arm32v7-gpiod and did gpioinfo I found SODIMM_63 is line 2 on gpiochip6.
2)# docker run --rm -it --device /dev/gpiochip6 --device .dev/spidev2.0 intersense123/spi_app.
3)my dts file is
intersense@Lenovo:~$ cat colibri-imx7_spidev_overlay.dts
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*

  • Copyright 2022 Toradex
    */

// Colibri imx7 spidev

/dts-v1/;
/plugin/;

/ {
compatible = “toradex,colibri-imx7d”,
“toradex,colibri-imx7d-emmc”,
“toradex,colibri-imx7s”;
};

/* Colibri SPI */
&ecspi3 {
#address-cells = <1>;
#size-cells = <0>;
status = “okay”;

    spidev@0 {
            /* Use compatible "rohm,dh2228fv" to bind spidev driver */
            compatible = "rohm,dh2228fv";
            reg = <0>;
            spi-max-frequency = <10000000>;
    };

};
is there any need to change in dts file or anywhere.
4)this is my main.py:
import spidev
import gpiod
import time

=== SPI SETUP ===

spi = spidev.SpiDev()
spi.open(2, 0) # Bus 2, CS 0 (We’ll manually control CS)
spi.max_speed_hz = 10 * 1000 * 1000
spi.mode = 0 # SpiMode 0
spi.bits_per_word = 16 # PackedMode = 1 equivalent

=== GPIO SETUP for manual CS ===

chip = gpiod.Chip(“gpiochip6”) # Assuming SODIMM 63 is on gpiochip6
cs_line = chip.get_line(2) # SODIMM 63 is gpiochip6 line 2

config = gpiod.LineRequest()
config.consumer = “spi-cs”
config.request_type = gpiod.LINE_REQ_DIR_OUT
cs_line.request(config)

=== SPI transfer buffers ===

spiData_Range = [0xD414, 0x0001]
rxBuffer =

while True:
count = 0
sum_1 = 0

for _ in range(20):
    cs_line.set_value(0)  # CS low (active)
    time.sleep(0.01)      # Sleep 10 ms

    # Transfer (send spiData_Range and read response)
    response = spi.xfer2(spiData_Range)
    
    cs_line.set_value(1)  # CS high (inactive)
    
    num_1 = response[0]  # Only first word received
    sum_1 += num_1
    count += 1

avg = sum_1 // count if count > 0 else 0
print(f"rxBuffer_1[0] = {avg}")

time.sleep(0.1)  # Sleep 100ms (optional)

Cleanup (you can use try/finally in real code)

spi.close()

cs_line.release()

5)i am getting output :[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
[69, 0, 0, 0]
please guide me for setup and all @ToradexAI

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


Hello! Thank you for providing all the details and code. Let’s walk through the setup and identify what might be causing your fixed SPI values.


1. Device Tree Overlay Validation

Your device tree overlay looks close to correct. Important things to check:

  • The SPI bus ecspi3 is correctly enabled.
  • The node under ecspi3 (spidev@0) uses compatible = "rohm,dh2228fv" to get spidev devices visible.
  • Ensure there are no other overlays or device tree fragments conflicting with your pinmux or enabling the same SPI bus differently.

Carefully verify that your overlay is properly built and deployed to the board. Here are steps you can follow:

  • Check for the expected SPI device in Linux:
    ls /dev/spidev*
    
    You should see /dev/spidev2.0.
  • Confirm the device tree overlay is applied using:
    cat /proc/device-tree/chosen/overlays/
    
    Or validate it in /sys/firmware/devicetree/base.

(Device Tree Overlay Guide)


2. GPIO and SPI Container Access

Your Docker commands and permissions look mostly correct. A couple of notes:

  • Ensure the container has access to /dev/spidev2.0 and /dev/gpiochip6.

  • When running the container, mount the host’s /dev directory, or explicitly pass both devices:

    docker run --rm -it \
      --device /dev/gpiochip6 \
      --device /dev/spidev2.0 \
      -v /dev:/dev \
      --device-cgroup-rule='c 254:* rmw' \
      <your-image>
    

    (How to Use SPI on Torizon)

  • Ensure your container’s user is a member of the right groups:


3. libgpiod Setup in Container

Make sure your Python environment in the container has the libgpiod library available.

For Debian-based images, the following packages are often required:

{
    "deps": [
       "libgpiod2"
    ],
    "devDeps": [
       "libgpiod-dev"
    ]
}

(libgpiod setup)


4. Python SPI Usage and Manual Chip Select

A few checks for your code:

  • Since you’re controlling CS manually, ensure that you do not let the SPI driver toggle CS itself. This is usually the default on spidev (it expects hardware CS). Because you control CS with GPIO, you must verify that the pinmux is NOT assigning SODIMM 63 to a native SPI CS function, and it is set as a GPIO in the overlay and not driven by the SPI hardware.

(SPI Pin Multiplexing)

Timing

  • The timing between toggling CS and performing the SPI transfer is important. Sleeping 10ms before each transfer is usually more than required, but it’s safe for debugging.

Data Format

  • spi.bits_per_word = 16 means each entry in spiData_Range is a single transfer of 16 bits (2 bytes). Confirm your slave device expects this format.
  • If your device expects 8-bit words, use spi.bits_per_word = 8.

Debug SPI Communication

  • You’re always receiving [69, 0, 0, 0]. This often indicates:
    • The wiring to the slave is not correct.
    • The slave is not selected (CS gating issue).
    • SPI mode or speed is mismatched.
    • The overlay is not properly setting up the pins for SPI and CS GPIO.
    • The device attached to SPI does not respond.

5. General Recommendations

  • Double-check the hardware connection (especially MISO, MOSI, SCK, CS).
  • Use an oscilloscope or logic analyzer to verify SPI lines toggle as expected.
  • Test the SPI bus with a known good slave, or try a loopback test (short MISO and MOSI).
  • If possible, try to use the default hardware-controlled CS first, see if it works, and then switch to manual CS if required.

Summary Checklist

  1. Confirm SPI bus and device tree overlay is loaded (SPI on Torizon).
  2. Validate GPIO pin SODIMM 63 is configured as a GPIO and not a hardware CS in the device tree (Pin Multiplexing).
  3. Ensure proper permissions and device nodes are passed into your container.
  4. Make sure your software setup matches the electrical and logical requirements of the SPI device.
  5. Check physical connections and logic levels for SPI signals.

If after all these steps you still get only constant values, there is likely a hardware wiring or incorrect CS handling issue.

Please follow the above, and let me know where you get stuck or if results change!

Best regards,
Toradex AI Assistant.

Hey @intersense.design,

Can you tell me a bit more about your setup? What carrier board are you using, what device are you connecting to the SPI bus? Let me know and I’ll try reproducing the issue.

Best regards,

I am using imx7 1d resistive colibri touch

Hey, @intersense.design,

Please, elaborate further on what you are trying to do. From your previous answer I assume you are using a resistive touch display. You said you are having problems with using SPI on Torizon, but the display doesn’t have an SPI interface. I need more information to be able to help you:

  • You are using a Colibri iMX7D, but what carrier board are you using it with? (Is it a Colibri Evaluation Board, an Iris, an Aster, a custom carrier board, etc)
  • Are you having problems with the display or with an SPI device?
  • What SPI device are you connecting to the board? (please provide the complete name of the device)
  • What is the expected result here? You said your output is several lines of [69, 0, 0, 0]. I can’t tell if this is expected or not since I don’t know your setup. What device are you trying to read this data from?

Best regards,

I am using marposs lvdt probe to read spi data with the help spidev module in torizon imx7.using python sample code.

Hey, @intersense.design,

This is too little information, and it makes it difficult to offer support for your specific project. In this case, I can only offer you generic advice on using SPI with our boards.

You can check our Test Results to confirm that the SPI interface is working for your build. You should check the “BSP Reference Multimedia (Upstream)” for the version of Torizon you are using. At least on the latest version, the SPI test has passed.

If you are having trouble reading the data from the probe, please go through our guide on How to Use SPI on Torizon. Don’t read the data from the python application at first, do it by reading the system files as shown in the article to validate that your system is configured correctly and your device is working. Also check our article on SPI usage on Linux.

If you manage to successfully read the SPI data from the system files, and you still have trouble using the interface inside your application, you can go through our list of partners and find one who can help you using SPI on python and develop your project. If you are having trouble finding a suitable partner, let me know and we can help you filter your options.

Best regards,