RS485 communication problem on Verdin AM62 with Ivy Carrier board

Hello Toradex community,

I am working with a AM62 SOM with an Ivy Carrier board and trying to set up a RS485 communication. Here i share you the tdx-info summery:

Software summary

Bootloader: U-Boot
Kernel version: 6.6.94-7.3.0-g7642ad324113 #1-Torizon SMP PREEMPT Thu Jul 3 08:47:26 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/e54388c03b414f15de5038757766a36da4957b04d84c897e8d44a069401c4dec/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: verdin-am62-15645393

Hardware info

HW model: Toradex Verdin AM62 WB on Ivy Board
Toradex version: 0075 V1.2A
Serial number: 15645393
Processor arch: aarch64

I had enable the Ivy device tree so i think i don’t need to use an overlay to enable RS485 peripheral.

torizon@verdin-am62-15645393:~$ cat /proc/device-tree/model
Toradex Verdin AM62 WB on Ivy Board

torizon@verdin-am62-15645393:~$ cat /proc/device-tree/compatible
toradex,verdin-am62-wifi-ivytoradex,verdin-am62-wifitoradex,verdin-am62ti,am625

I am working on a single project container with Python. I configure docker-compose.yml to have access to the UART2 of the board. Here i share you the configuration:

services:
test-debug:
build:
  context:.
  dockerfile: Dockerfile.debug
image: ${LOCAL_REGISTRY}:5002/test-debug:${TAG}
ports:- ${DEBUG_SSH_PORT}:${DEBUG_SSH_PORT}- 

${DEBUG_PORT1}:${DEBUG_PORT1}
devices:
  - "/dev/verdin-uart2:/dev/verdin-uart2"
  - "/dev/gpiochip2:/dev/gpiochip2"
  - "/dev/gpiochip3:/dev/gpiochip3"
  
group_add:
  - "20"

i made a simple script in python to send a “Hello world” and catch it with a RS485 to USB converter.

Here is the script:

import sys
import serial
import serial.rs485
import time


def test_rs485_loopback():
    ser = serial.Serial("/dev/verdin-uart2",9600, 8, 'N', 1, timeout=1)
    ser.reset_input_buffer()
    ser.reset_output_buffer()
    if not ser.is_open:
        ser.open()

    if ser.is_open:
        ser.rs485_mode = serial.rs485.RS485Settings(delay_before_tx=0.001, delay_before_rx=0.001, loopback=False)

        print("Serial port opened successfully.")
        print(ser.name)
        test_data = b'Hello RS485'
        time.sleep(0.01)
        ser.write(test_data)
        time.sleep(0.05)
        print(f"Wrote {len(test_data)} bytes: {test_data}")
        s = ser.read(len(test_data))
        print(f"Read {len(s)} bytes: {s}")

When i debug the container, over the serial i only receive ‘0x00’ instead of b’Hello RS485’.

Can anyone tell me if i’m doing the things rigth? or i have to configure something else to acces to the RS485 port?

Thank you in advance.

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,

Based on your setup with the Verdin AM62 on the Ivy Carrier Board, your configuration looks correct for accessing UART2 (1). The Verdin AM62 modules are compatible with the Ivy Carrier Board and support RS-485 communication (1).

Verifying RS-485 Hardware Support

First, confirm that RS-485 is properly enabled on your system. The Ivy Carrier Board supports RS-485 on UART_2 with transceiver functionality (1). You can verify the device tree configuration is loaded correctly since you mentioned using the Ivy device tree.

Potential Issues and Solutions

1. Device Tree RS-485 Configuration

While you’re using the Ivy device tree, RS-485 mode might need explicit enabling. Based on similar issues reported with Verdin modules on Ivy boards (2), you may need to ensure RS-485 is properly configured in the device tree or enable it programmatically.

2. Hardware Connection Verification

The issue where you’re receiving 0x00 bytes instead of your transmitted data suggests a potential hardware or configuration problem. This could be related to:

  • Transceiver Direction Control: The RS-485 transceiver needs proper direction control to switch between transmit and receive modes (3)
  • Signal Levels: Ensure your RS-485 to USB converter is properly connected and configured

3. Software Configuration Enhancement

Try modifying your Python script to explicitly configure RS-485 settings:

import sys
import serial
import serial.rs485
import time

def test_rs485_loopback():
    ser = serial.Serial("/dev/verdin-uart2", 9600, 8, 'N', 1, timeout=1)
    ser.reset_input_buffer()
    ser.reset_output_buffer()
    
    if not ser.is_open:
        ser.open()

    if ser.is_open:
        # Configure RS-485 with more explicit settings
        rs485_settings = serial.rs485.RS485Settings(
            rts_level_for_tx=True,
            rts_level_for_rx=False,
            delay_before_tx=0.001,
            delay_before_rx=0.001,
            loopback=False
        )
        ser.rs485_mode = rs485_settings
        
        print("Serial port opened successfully.")
        print(f"Port: {ser.name}")
        print(f"RS485 mode: {ser.rs485_mode}")
        
        test_data = b'Hello RS485'
        time.sleep(0.01)
        bytes_written = ser.write(test_data)
        ser.flush()  # Ensure data is transmitted
        time.sleep(0.05)
        
        print(f"Wrote {bytes_written} bytes: {test_data}")
        s = ser.read(len(test_data))
        print(f"Read {len(s)} bytes: {s}")
        
        ser.close()

if __name__ == "__main__":
    test_rs485_loopback()

4. Debugging Steps

  1. Check RS-485 Status: Verify if RS-485 mode is actually enabled by checking the serial port settings
  2. Test with Simple UART: Try the same code without RS-485 settings to see if basic UART communication works
  3. Hardware Verification: Use an oscilloscope or logic analyzer to verify signal transmission on the RS-485 lines

5. Alternative Configuration

If the device tree approach doesn’t work, you might need to configure RS-485 using ioctl calls directly, as mentioned in community discussions (2). This would involve using lower-level system calls to configure the UART for RS-485 operation.

Container Configuration

Your Docker container configuration looks correct for accessing the UART device. The device mapping and group permissions should allow access to /dev/verdin-uart2 (1).

Try the enhanced script above and let us know if you still encounter issues. The key is ensuring proper RS-485 transceiver control and verifying that the hardware connections are correct.

Best regards, Toradex AI Assistant.

Hi @gvallasciani!

Sorry for the delayed reply.

Were you able to solve the issue? If not, did you make some progress?

Best regards.