Verdin iMX8M Mini – RS485 RX issues and SC16IS762 IRQ instability on custom carrier board

AYJF · May 8, 2026, 12:25pm

Hello Toradex Support Team,

I am working with a custom carrier board based on the Ivy Carrier Board V1.1, using the Verdin iMX8M Mini Quad 2GB Wi-Fi / Bluetooth IT (No CAN) V1.1A module.

Hardware Modifications

I made the following modifications compared to the Ivy carrier:

Converted the RS232 interface to RS485:
- Using SN65176BDR transceivers
- Isolation via ISO6721RBDR
- Similar topology to the existing RS485 design on the Ivy carrier
Added an external SPI UART:
- SC16IS762IPW connected via ECSPI3 (SPI3)
- Two RS485 transceivers (SN65HVD72DR) connected to the SC16 UART channels

Issues Observed

1. RS485 Communication (SN65176BDR)

TX works correctly
RX does not work reliably
Received data appears as garbage / corrupted

This happens on both RS485 channels.

2. SC16IS762 Interrupt Issue

The interrupt line (connected to GPIO5_IO3 / SPDIF_TX pin) appears unstable
The IRQ is continuously firing
System shows high CPU usage:

irq/168-spi2.0 ~95-100% CPU

This suggests an interrupt storm or incorrect IRQ configuration

Device Tree Configuration

Below is the relevant device tree configuration:

/* ---------------- PINCTRL ---------------- */
&iomuxc {

	pinctrl_sc16is762_int: sc16is762-int {
		fsl,pins =
			<MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 0x140>; /* GPIO for SC16IS762 interrupt */
	};

	pinctrl_ecspi3: ecspi3grp {
		fsl,pins =
			<MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK 0x6>,
			<MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI 0x6>,
			<MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO 0x6>,
			<MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25 0x6>;
	};
};

/* ---------------- SPI3 + SC16IS762 ---------------- */
&ecspi3 {
    status = "okay";

    #address-cells = <1>;
    #size-cells = <0>;

    cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;

    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_sc16is762_int>;

    sc16is762: uart@0 {
        compatible = "nxp,sc16is762";
        reg = <0>;
        spi-max-frequency = <1000000>;

        clocks = <&sc16is762_clk>;

        interrupt-parent = <&gpio5>;
        interrupts = <3 IRQ_TYPE_LEVEL_LOW>;

        linux,rs485-enabled-at-boot-time;
        rs485-rts-active-low;
        rs485-rts-delay = <1 0>;
    };
};

Additional Observations

The SC16IS762 driver loads correctly:
- /dev/ttySC0 and /dev/ttySC1 are created

dmesg shows:

spi2.0: ttySC0 ... is a SC16IS762
spi2.0: ttySC1 ... is a SC16IS762

However:
- IRQ appears constantly active
- GPIO debug shows the pin as “GPIO UNCLAIMED”

Attachments

I have attached images of the relevant schematic sections for:

RS485 implementation (SN65176BDR + ISO6721RBDR)
SC16IS762 + SPI + interrupt connection

I can also provide the full schematic PDF if needed.

Questions

Is the pin configuration for GPIO5_IO3 (SPDIF_TX) correct for use as an interrupt input?
What is the recommended pad configuration (pull-up/down) for SC16IS762 IRQ on i.MX8MM?
Could the IRQ storm be caused by incorrect pinmux or missing bias configuration?
Are there any known requirements or constraints when using ECSPI3 (SPI3) on Verdin iMX8M Mini without CAN?
For RS485:
- Are there known issues when converting RS232 to RS485 using SN65176BDR on this platform?
- Could incorrect DE/RE control or polarity cause RX corruption?

Summary

RS485 TX works, RX is corrupted
SC16IS762 IRQ is unstable and causes high CPU usage
Suspecting GPIO/pinctrl or hardware biasing issue

Any guidance on validating the interrupt configuration and RS485 design would be greatly appreciated.

Best regards,
Alvaro Jimenez

ToradexAI · May 8, 2026, 12:25pm

Hi, I’m the Toradex AI Assistant.

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

I’d be glad to help with your RS485 and SC16IS762 issues! To provide the most accurate guidance, could you let me know which OS and version you are running on your Verdin iMX8M Mini? For example:

Hardware: Verdin iMX8M Mini Quad 2GB Wi-Fi / Bluetooth IT (No CAN) V1.1A
OS: Torizon OS 6.8.2, Torizon OS 7.2.0-build.13, Yocto BSP 7, etc.

You can get detailed information about your setup using the tdx-info command - see this guide for more details.

Initial Analysis of Your Issues

Based on the information provided, I can see you’re experiencing:

RS485 RX corruption despite working TX
SC16IS762 interrupt storm causing high CPU usage

RS485 Configuration Insights

From the community discussion on a similar setup (1), there are some key considerations for RS485 on Verdin iMX8M Mini:

Device Tree RS485 Settings

For proper RS485 operation, the device tree configuration should include proper direction control (1):

&uart3 {
    status = "okay";
    linux,rs485-enabled-at-boot-time;
    rs485-rts-active-low; // Adjust polarity as required by your board
    // Remove rs485-rx-during-tx; to suppress echo
};

Echo Suppression

The documentation indicates that RS485 can echo transmissions if the transceiver’s receive line is enabled during transmission (1). The rs485-rx-during-tx property should be removed unless you specifically need to receive while transmitting, as this enables loopback (echo) (1).

Device Tree Overlay Considerations

When working with custom pin configurations, the device tree overlay approach is recommended (2). Your pin multiplexing configuration needs to ensure:

Proper pin function assignment
Correct pad configuration values
No conflicting peripheral usage

Once you provide your OS version, I can give you more specific guidance on:

Proper interrupt configuration for SC16IS762
Recommended pad settings for GPIO5_IO3
RS485 direction control validation
SPI3 configuration specifics for your platform

Best regards, Toradex AI Assistant.

Did you like my answer?

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

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

AYJF · May 8, 2026, 12:31pm

Yes for RS485 Communication (SN65176BDR – Native UARTs)

TX works correctly
RX does not work reliably
Received data appears as garbage / corrupted

This occurs on the native UART interfaces.

For reference, I enabled RS485 in the device tree as follows:

&uart3 {
    status = "okay";
    linux,rs485-enabled-at-boot-time;
    rs485-rts-active-low;
    // rs485-rx-during-tx;
};

ToradexAI · May 8, 2026, 12:32pm

Based on your RS485 configuration and the fact that TX works but RX is corrupted, this suggests a direction control timing or polarity issue. Let me help you troubleshoot this systematically.

RS485 Direction Control Analysis

Your device tree configuration looks correct for basic RS485 operation(1). However, there are several factors that could cause RX corruption:

1. RTS Polarity Verification

The rs485-rts-active-low setting assumes your transceiver’s DE (Driver Enable) pin is active when RTS is low(1). For the SN65176BDR, verify that:

DE pin is connected to RTS signal
RE# (Receiver Enable) pin is connected to inverted RTS or separate control
The polarity matches your hardware design

2. Missing RTS Delay Configuration

The i.MX 8M Mini UART supports RTS delay timing, which can be crucial for proper RS485 operation(1). Try adding delay configuration:

&uart3 {
    status = "okay";
    linux,rs485-enabled-at-boot-time;
    rs485-rts-active-low;
    rs485-rts-delay = <1 1>; /* pre-delay, post-delay in milliseconds */
};

3. Hardware Verification Steps

According to the documentation, the i.MX 8M Mini UART block has built-in support for RS-485 auto RTS for controlling the direction of the RS-485 transceiver(1). However, you should verify:

Signal integrity: Use an oscilloscope to check:
- RTS signal transitions properly during TX/RX
- Data signal quality on the RS485 bus
- Timing between RTS assertion and data transmission
Transceiver configuration: Ensure the SN65176BDR is properly configured for half-duplex operation

4. Alternative Configuration Method

If device tree configuration doesn’t resolve the issue, you can enable RS-485 using ioctl from userspace(1). The documentation references this approach for troubleshooting.

Additional Considerations

Since you mentioned this is based on the Ivy Carrier Board design, ensure that:

Your custom PCB maintains the same signal routing and termination
Power supply decoupling is adequate for the transceivers
Ground planes are properly designed to minimize noise

Could you also confirm which OS version you’re running? This will help me provide more specific guidance for your platform configuration.

Best regards, Toradex AI Assistant.

Did you like my answer?

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

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

AYJF · May 10, 2026, 3:26pm

I’m more worry about this SC16IS762 Interrupt Issue

The interrupt line (connected to GPIO5_IO3 / SPDIF_TX pin) appears unstable
The IRQ is continuously firing

bw908 · May 11, 2026, 5:39pm

Random tidbit but we’ve seen this with that SPI-to-UART bridge in the past on our hardware. The driver doesn’t seem to set itself up as an edge triggered IRQ, so if the line is stuck low, it will constantly fire the IRQ and consume a CPU core in the process. I would confirm with a meter or other means the state of the IRQ line - this will point to whether it’s a HW/config/pinmux issue (line is actually stuck low or something is constantly generating interrupts from the bridge) or a SW issue (line value is deasserted but system thinks otherwise)

alex.tx · May 12, 2026, 3:38pm

@AYJF
Let’s avoid mixing multiple topics and debug the issue step by step.

I suggest we first focus on the SC16IS762 and test it as a basic UART, without connecting the RS485 transceivers. For this initial test, you can use a simple loopback connection to another free UART on the Verdin module, or to a USB-to-serial adapter connected to your development machine.

Could you please also provide higher-quality schematic snippets? The current ones are difficult to read, especially the signal names and component pin labels. Please include the relevant connections between the SC16IS762 and the Verdin module so we can clearly see how SPI, chip select, interrupt, reset, clock, and UART signals are routed.

Regarding the interrupt storm issue:
Since the interrupt is connected to the SPDIF_TX pad, please make sure the pad is configured as GPIO, not as S/PDIF or another alternate function.

The pinctrl entry should be similar in concept to:

pinctrl_sc16is762_int: sc16is762intgrp {	
     fsl,pins = <
		MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 0x1c4	
               >;
    };

Please also check the behavior of the SC16IS762 INT pin using oscilloscope.
As a debug step, you can temporarily remove the interrupt-parent and interrupts properties from the SC16IS762 node and check whether the high CPU usage disappears. You can also try IRQ_TYPE_EDGE_FALLING instead of IRQ_TYPE_LEVEL_LOW for testing.
Once the SC16IS762 UART functionality will be fixed, we can continue debugging the RS485-related issues separately.

AYJF · May 12, 2026, 10:58pm

@alex.tx Thank you very much. I will follow your suggestions step by step and will get back to you as soon as possible. In the meantime, I have attached the complete schematics PDF for your reference.

46806005 - Ivy_compressed_removed.pdf (1.6 MB)

alex.tx · May 21, 2026, 3:07pm

Michael Park The schematic looks OK. I asked for a higher-quality version just to better understand its functionality.
I have suggested some initial debugging steps to the customer. Let’s wait for their response.

Alexander Samutin
Toradex

Senior Field Application Engineer