Verdin imx8mp rs485 RTS configuration

Technical Support
, ,
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

RS-485 Configuration Issue Analysis

Based on your description, you’re experiencing a common issue with RS-485 configuration on the Verdin i.MX8M Plus. The problem appears to be related to how the kernel handles the RS-485 RTS control signal polarity and timing.

Device Tree Configuration Review

Your device tree configuration looks mostly correct for enabling RS-485 mode(1). However, there are a few points to consider:

  1. Pin Configuration: You’re using SODIMM 133 (SAI2_TXFS) as the RTS/CTS signal, which should work for RS-485 direction control(1).

  2. RS-485 Properties: The properties you’re using are correct according to the documentation(1):

    • linux,rs485-enabled-at-boot-time
    • rs485-rts-active-high
    • rs485-rx-during-tx

Potential Solutions

1. Verify Kernel Support

The i.MX 8M Plus UART block has built-in support for RS-485 auto RTS control(1). Make sure your BSP 7.5.0 kernel properly supports these device tree properties.

2. Check RTS Pin Configuration

According to the documentation, on Toradex carrier boards, the following flags should typically be used(1):

/* Enable RS485 mode: */
rs485conf.flags |= SER_RS485_ENABLED;

/* or, set logical level for RTS pin equal to 0 when sending: */
rs485conf.flags &= ~(SER_RS485_RTS_ON_SEND);

/* Set logical level for RTS pin equal to 1 after sending: */
rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;

/* Enable receiver during sending, required for i.MX devices */
rs485conf.flags |= SER_RS485_RX_DURING_TX;

3. Alternative GPIO-based Approach

If the built-in RS-485 support isn’t working as expected, you might need to consider using a GPIO-based approach for RTS control(2). This would involve:

  • Configuring the RTS pin as a GPIO instead of UART RTS
  • Using rts-gpios property in the device tree
  • Managing the GPIO state in software

4. Userspace Configuration

You can also try configuring RS-485 mode from userspace using ioctl calls(1). The behavior you observe with minicom suggests that proper userspace configuration might resolve the issue.

Boot-time Behavior

The issue you’re experiencing during boot (RTS staying high) is critical for RS-485 bus integrity. This suggests that the kernel driver might not be properly initializing the RS-485 mode at boot time, despite the linux,rs485-enabled-at-boot-time property.

Recommended Next Steps

  1. Verify BSP Version: Ensure your BSP 7.5.0 includes the latest RS-485 support for i.MX8M Plus
  2. Check Kernel Logs: Look for any RS-485 related messages during boot
  3. Test with Standard Tools: Use the stty command-line utility to verify RS-485 configuration(1):
# stty -F /dev/verdin-uart1 115200
# echo Test > /dev/verdin-uart1
  1. Consider GPIO Alternative: If the hardware RS-485 support continues to cause issues, implementing GPIO-based RTS control might be more reliable for your specific transceiver requirements.

The fact that minicom works correctly suggests the hardware and basic driver support are functional, but there may be an initialization timing or configuration issue specific to the boot-time RS-485 setup.

Best regards,
Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.