Problem using UART3 on Ixora+Apalis

Good morning everyone,

I am working on my usual platform:

Apalis iMX8QM V1.1E

Ixora V1.2A

I have always used only UART2 (with RS232 on X21).

Now I need to use UART3 (with RS232 on X21) as well.

So my final goal is to manage 2 RS232 at the same time.

I will try to describe the problem I am encountering: on pin 1 of X21, as soon as I turn on the board, I find 12V. I don’t really understand why, but after a while that value drops and the port starts working properly. I don’t face up the same problem on UART3.

Unfortunately, this small issuecauses the power board that Ixora has to interface with to malfunction.

To confirm that the problem is caused by that high value, I tried something else: I kept pin 1 of X21 disconnected and connected it only 5 seconds after power-up… in this case, communication works correctly.

Can anyone tell me how to solve this problem?

Hi, I’m the Toradex AI Assistant.

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


UART Configuration on Ixora V1.2A

Based on the available documentation for Ixora carrier boards, I can provide information about the UART interfaces and RS232 connectivity.

UART Interface Configuration

The Ixora carrier board features 4 UART interfaces connected as follows (1):

  • UART1 to connector X22 through an RS232 transceiver
  • UART2 to connector X21 through an RS232 transceiver
  • UART3 to connector X21 through an RS232 transceiver and to connector X27
  • UART4 to connector X27

X21 Connector Pinout

According to the Ixora V1.3 datasheet, the RS232 Header (X21) has the following configuration (2):

Pin Signal Name I/O Type
1 UART3_RS232_RXD I
2 NC
3 UART2_RS232_RXD I
4 UART2_RS232_RTS O
5 UART2_RS232_TXD O
6 UART2_RS232_CTS I
7 UART3_RS232_TXD O
8 NC
9 GND

UART3 Control Configuration

For UART3 usage, the documentation indicates that it’s possible to disconnect the UART3_RXD signal from the RS232 transceiver and put the transceiver in high impedance state (1). This is controlled through:

  • JP3 jumper: Can be disassembled to disconnect UART3_RXD from the RS232 IC12 MAX3243 transceiver
  • GPIO control: Pin 180 of the MXM3 connector can force the IC12 transceiver into high impedance state

Standard UART Device Names

For software configuration, the Apalis family uses these standard device names (3):

Toradex Name Device Symlink Note
UART1 /dev/apalis-uart1 debug (console) with RTS/CTS, DTR/DSR and RI
UART2 /dev/apalis-uart2 general-purpose with RTS/CTS
UART3 /dev/apalis-uart3 general-purpose
UART4 /dev/apalis-uart4 general-purpose

Regarding the 12V Issue

The high voltage issue you’re experiencing on pin 1 (UART3_RS232_RXD) at startup may be related to the RS232 transceiver initialization sequence. The documentation mentions that the transceiver can be put into high impedance state, which suggests there may be initialization behavior that could cause temporary voltage spikes.

Based on the available documentation, I don’t have specific information about the exact cause of the 12V startup issue on your Ixora V1.2A. However, the workaround you’ve discovered (delaying connection by 5 seconds) suggests this is indeed related to the power-up sequence of the RS232 transceiver.

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.

Ok I red the documentation as well but I can’t understand if it is possible to solve my problem or not.

What do I have to do to put the transreceiver at High impedance state? Furthermore, Why I don’t face up the same problem on UART2?

Hello @Merlin !

Thank you for contacting Toradex Support.

Could you please clarify how exactly you are wiring your external circuit to the X21 connector? This will help us have a clearer image of what might be causing the issue.

Regardless, what might be happening is that the RS232 startup behavior might be causing said spike, as the transceiver may drive its output lines to a valid level, in this case being 12V.
Removing JP3, which disconnects UART3 from the RS232 transceiver, may help by preventing any unwanted drive from the SoC side, so please try that and see if it changes the behavior; As mentioned by the bot.

Also, you can prevent this condition by keeping the UART3 RS232 transceiver in High-Impedance (Force-Off) state during startup. This can be done by controlling the Force-Off pin connected to MXM3 pin 180. Though this will achieve the same result as removing JP3 but with more steps.

Please let us know how it goes.

Hi @joaom.tx

I connect directly to the X21 connector with cables. I can attach a photo if needed, showing the direct connection of the cable to the necessary pins on X21.

To be honest, the spike I reported is on pin 7 of X21, not on pin 1.

Basically, when powering up on PIN7 of X21, i.e., UART3_RS232_TXD (in fact, a malfunction on PIN1 would have been abnormal).

This causes the serial communication on the other board to go haywire. I need to find a way to make UART3 work exactly like UART2.

João Victor Couto de Oliveira Martins, Oct 21, 2025, 14:03

OK, being that the spike is coming from pin 7, it is for sure caused by the RS-232 transmitter output. This is part of normal RS-232 operation, but it can interfere with sensitive electronics if they expect a quiet line during startup.
On UART2, this doesn’t happen because its transceiver has a different default configuration as its Force-Off pin is tied so the driver stays high-impedance until the system is ready, while UART3’s transceiver comes up enabled by default.
Please try removing JP3 to see if this behavior persists.

João Victor Couto de Oliveira Martins
Toradex

Well, this confirms what I said in an earlier reply.

Removing JP3, which disconnects UART3 from the RS232 transceiver, may help by preventing any unwanted drive from the SoC side, so please try that and see if it changes the behavior; As mentioned by the bot.

Please try this and see if the behavior continues or not.

Hi @joaom.tx ,

I removed JP3 but I continue to see the spike on PIN7 of X21 - UART3_RS232_TXD. The problem persists.

Maybe we can manage a different solution?

Hi @joaom.tx ,

Do you think it is possible to solve this issue editing the device tree ?

Thanks

Yes, this can be solved through the device tree by keeping the UART3 RS-232 transceiver disabled during boot. On the Ixora board, the transceiver’s Force-Off line is connected to pin 180. You can add a GPIOhog in your DTO to hold it high (transceiver off) at startup, then drive it low later from userspace to enable UART3:

 {
    gpio-hog-uart3-rs232-forceoff {
        gpio-hog;
        gpios = <&gpioX N GPIO_ACTIVE_HIGH>; 
        output-high; 
        line-name = "uart3-rs232-forceoff";
    };
};

This ensures the RS-232 driver stays in High-Impedance during power-up.
For guidance on creating and applying Device Tree Overlays, please refer to our documentation:
How to Write Device Tree Overlays

Hello,

I’m trying to implement the solution suggested here on the Toradex Community regarding keeping the UART3 RS-232 transceiver disabled during boot by adding a GPIO-hog to force the “RS232 Force-Off” line high at startup.

I had the exact same problem described in the original thread, so I tried to reproduce the recommended approach.

On the Ixora V1.2A with Apalis iMX8, the RS-232 transceiver’s Force-Off line is connected to pin 180, so in my overlay I also need something like:

{
gpio-hog-uart3-rs232-forceoff {
gpio-hog;
gpios = <&gpioX N GPIO_ACTIVE_HIGH>;
output-high;
line-name = “uart3-rs232-forceoff”;
};
};

The objective is the same: keep the RS-232 driver in high-impedance during boot, and then pull the line low from userspace when needed.

What I already did

Following your documentation, I installed and cloned exactly the kernel branch recommended for Device Tree modifications:

git clone -b toradex_6.6-2.2.x-imx git://git.toradex.com/linux-toradex.git

Inside an Ubuntu virtual machine (to avoid Windows-related issues), I successfully tested that overlays build and work: for example, I modified the LVDS overlay and confirmed it loads correctly on my Apalis iMX8 + Ixora board.

The issue: Overlay fails as soon as I add any include

However, when I try to build the overlay for UART3 Force-Off, I always get a DTC syntax error only when an include is present, even the simplest header:

Example:

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/pads-imx8qm.h>

/ {
compatible = “toradex,apalis-imx8”;
};

Build command:

dtc -@ -I dts -O dtb
-o apalis-test-overlay.dtbo
-i ~/linux-toradex/include
-i ~/linux-toradex/include/dt-bindings
apalis-test-overlay.dts

Error:

Error: apalis-test-overlay.dts:5.1-9 syntax error
FATAL ERROR: Unable to parse input tree

I double-checked:

  • header files exist (e.g. gpio.h, pads-imx8qm.h)

  • no BOM in the file

  • no hidden characters

  • includes paths are correct

If I remove all #include, the overlay compiles — but obviously I need the macros (GPIO_ACTIVE_HIGH, pad control macros, etc.).

Since I already have another overlay for my LVDS display configuration, I would also like to know whether:

This GPIO-hog configuration can be safely included in the same overlay where I modify the LVDS panel,
or
It is recommended to keep them as two separate overlays (e.g., lvds-overlay.dtbo and uart3-forceoff.dtbo) and load both through overlays.txt.

I have successfully configured the development environment for the kernel and can run make to compile overlays. However, I have encountered an issue when trying to apply the overlay for controlling the UART3 RS-232 transceiver.

Overlay Implementation

Following the guidance in your forum post, I created an overlay to disable the UART3 RS-232 transceiver during boot by setting the “RS232 Force-Off” line high. Below is the overlay I wrote:

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/pads-imx8qm.h>

&iomuxc {
    pinctrl_forceoff: forceoffgrp {
        fsl,pins = <IMX8QM_USDHC2_CMD_LSIO_GPIO5_IO25 0x20>;
    };
};

&gpio5 {
    gpio-hog-uart3-rs232-forceoff {
        gpio-hog;
        gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "uart3-rs232-forceoff";

        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_forceoff>;
    };
};

The goal is to keep the RS-232 driver in high-impedance during boot and then pull the GPIO line low from userspace when needed.

Problem Encountered

When I try to load the overlay, the system freezes during boot. The overlay seems to be causing the system to hang at the boot stage, preventing the system from loading the device tree correctly.

Log from Boot

Here’s the log that I see when trying to boot:

Normal Boot
Hit any key to stop autoboot:  0
MMC: no card present
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
5389 bytes read in 1 ms (5.1 MiB/s)
## Executing script at 9d480000
Loading DeviceTree: imx8qm-apalis-v1.1-eval.dtb
176936 bytes read in 6 ms (28.1 MiB/s)
70 bytes read in 1 ms (68.4 KiB/s)
Working FDT set to 9d400000
Applying Overlay: apalis-imx8_panel-lvds-dual-channel-1080p_overlay.dtbo
902 bytes read in 1 ms (880.9 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
8301969 bytes read in 188 ms (42.1 MiB/s)
Bootargs: root=PARTUUID=4ecbb7c9-02 ro rootwait console=tty1 console=ttyLP1,115200
   Uncompressing Kernel Image to 0
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
Booting from mmc failed!
SCRIPT FAILED: continuing...
starting USB...
Bus usb@5b040000: USB EHCI 1.00
Bus usbh3: XHCI-imx8 init hccr 0x000000005b130000 and hcor 0x000000005b130080 hc_length 128
Register 2000820 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@5b040000 for devices... 1 USB Device(s) found
scanning bus usbh3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
ethernet@5b040000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@5b040000
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3

Details from gpioinfo and Pin Check

I ran gpioinfo and found that GPIO5 25 corresponds to pin 180. However, I also checked the datasheet for the Apalis iMX8 and found that pin 180 corresponds to USDHC2_CMD, which is described as LSIO.GPIO5.IO25 and connected to the USDHC2_CMD function in the system(180 USDHC2_CMD H44 CONN.USDHC2.CMD AUD.MQS.L LSIO.GPIO5.IO25 GPIO ALT0 PD VDD_USDHC2_1P8_3P3).

Additionally, when I looked at the pin details through the debug interface using:

grep -r "pin 180" /sys/kernel/debug/pinctrl/

I found the following:

/sys/kernel/debug/pinctrl/system-controller:pinctrl/pinconf-pins:pin 180 (IMX8QM_COMP_CTL_GPIO_1V8_3V3_QSPI1): 0x5d4a0
grep: /sys/kernel/debug/pinctrl/system-controller:pinctrl/pinmux-select: Invalid argument
/sys/kernel/debug/pinctrl/system-controller:pinctrl/pinmux-pins:pin 180 (IMX8QM_COMP_CTL_GPIO_1V8_3V3_QSPI1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
/sys/kernel/debug/pinctrl/system-controller:pinctrl/pins:pin 180 (IMX8QM_COMP_CTL_GPIO_1V8_3V3_QSPI1) 0:? system-controller:pinctrl

Can you please advise on how to modify the overlay to make it work correctly without causing the system to freeze during boot?