Ivi plus verdin imx8 uart 2 and 3 issue

Dear support,

we are using ivy plus v. 1.0A carrier board PN 01781000 with Verdin imx8 MM 2GB V1.1D PN 00591103.

OS release: Linux verdin-imx8mm-08606292 6.6.84-7.2.0-devel
Device Tree: imx8mm-verdin-nonwifi-ivy.dtb

We are facing an issue about uart serial ports: while uart 3 tx and rx signal available on connector J17 works fine with voltage level between 0 and 1,8V, on both serial port uart 1 and uart 2, the signals at 1,8V level swing between 0 and about 1,1V and cannot reach the rigth 1,8V level.

Signal was measured by scope on pin A1 to A4 of U16 level translator chip.

Attached the schematic draft of ivy plus.

Issues involve all 4 output signal from Verdin imx8: UART1 TXD, UART1 RTS, UART2 TXD, UART2 RTS

Is there any setting to permit to these signals to swing correctly up to 1,8V?

Best

Roberto

Hi, I’m the Toradex AI Assistant.

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


Hello Roberto,

Thank you for the detailed description of your UART signal level issue on the Ivy Plus carrier board. This is an interesting hardware-level problem that requires examining the device tree configuration and pin settings.

Understanding Your Setup

Based on your configuration:

  • Hardware: Ivy Plus V1.0A (PN 01781000) with Verdin iMX8MM 2GB V1.1D (PN 00591103) (1)
  • Device Tree: imx8mm-verdin-nonwifi-ivy.dtb
  • Issue: UART1 and UART2 signals only reaching ~1.1V instead of the expected 1.8V level

Device Tree Configuration Analysis

The voltage levels you’re experiencing suggest a potential pinmux or drive strength configuration issue. In device trees, pin configurations include drive strength and voltage settings that can affect signal levels (2).

Recommended Investigation Steps

1. Check Current Pin Configuration

First, examine your current device tree to see how UART1 and UART2 pins are configured. The device tree controls both the pin multiplexing and electrical characteristics (2).

2. Device Tree Customization Approach

You may need to create a custom device tree overlay to adjust the pin drive strength settings. The process involves (3):

  1. Choose the base device tree that matches your hardware platform
  2. Customize the device tree by modifying pin configurations
  3. Compile and deploy the updated configuration

3. Pin Drive Strength Settings

The issue might be related to insufficient drive strength on the UART pins. Device tree pin configurations typically include drive strength parameters that control the output voltage levels and current capability (2).

Next Steps

To provide more specific guidance, could you please:

  1. Confirm your exact OS version: You mentioned “6.6.84-7.2.0-devel” - could you run tdx-info to get complete system information? You can find details about this command at Getting Device Information with Tdx-Info | Toradex Developer Center

  2. Check if this occurs with default configurations: Have you made any custom device tree modifications, or are you using the standard Ivy device tree?

  3. Verify UART3 configuration: Since UART3 works correctly, comparing its pin configuration with UART1/UART2 might reveal the difference.

The solution will likely involve creating a device tree overlay that adjusts the pin drive strength or voltage settings for the affected UART pins. Once we confirm your exact platform details, I can provide more specific device tree modification guidance.

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.

Hi @signo_ri,

Taking a look at the schematics of the Ivy board, it looks like there is nothing that pulls these signals low. The signals UART1 TXD, UART1 RTS, UART2 TXD, and UART2 RTS are outputs from the SODIMM pins on the module, and are pulled up to 1.8V at the translator, as you see on the schematics. From a design perspective, everything looks good.

It could be that there might be a design issue on that particular verdin module or the Ivy carrier board (most likely the Ivy, because if it were the module, our functional testers would have caught an issue on the UARTs). So I would suggest that you test with a different Verdin iMX8MM module if you have any, and also with a different carrier board (different Ivy or any other compatible board). This would help us understand if there is an issue with the particular hardware itself. Once confirmed, we can look into either replacing or fixing that hardware for you.

You are right, we will buy 2 new boards and perform some more test. Anyway it seems to me strange that all 4 signals of UART1 and UART2 have the issue while UART 1 not.

Here below, for further investigation, you can find the complete system information and the steps we performed.

Software summary

Bootloader: U-Boot

Kernel version: 6.6.108-7.4.0 #1 SMP PREEMPT Thu Sep 25 09:00:10 UTC 2025

Kernel command line: root=PARTUUID=0cb37ad0-02 ro rootwait console=tty1 console=ttymxc0,115200

Distro name: NAME=“TDX Wayland with XWayland Upstream”

Distro version: VERSION_ID=7.4.0-build.10

Distro variant: -

Hostname: verdin-imx8mm-08606292

Hardware info

HW model: Toradex Verdin iMX8M Mini on Ivy

Toradex version: 0059 V1.1D

Serial number: 08606292

Processor arch: aarch64

From the Toradex Easy Installer, we installed the latest “Upstream image version” proposed online by the Toradex server. Then we changed the fdtfile and the fdt_board variable in U-Boot. This is the current output of printenv:

fdt_board=ivy

fdtfile=imx8mm-verdin-nonwifi-ivy.dtb

(complete printenv attached below, as captured)

We checked the device tree and everything looks correct, however the UART1 and UART2 signals still measure ~1.1 V instead of the expected 1.8 V logic level.

Could you please suggest what else we should verify or try to solve this issue?

In particular, are there known settings (IOMUX/pinctrl, pad control, voltage domain, PMIC/regulator, or board-level configuration) that could force UART pins to operate at a lower I/O voltage, even if the DTB appears correct?

Thank you in advance.

Best regards,

arch=arm

baudrate=115200

board=verdin-imx8mm

board_name=verdin-imx8mm

boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}

boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr -q ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi

boot_efi_bootmgr=if fdt addr -q ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi

boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}

boot_net_usb_start=usb start

boot_prefixes=/ /boot/

boot_script_dhcp=boot.scr

boot_scripts=boot.scr.uimg boot.scr

boot_syslinux_conf=extlinux/extlinux.conf

boot_targets=mmc1 mmc0 dhcp

bootcmd=run distro_bootcmd

bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr -q ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;

bootcmd_mmc0=devnum=0; run mmc_boot

bootcmd_mmc1=devnum=1; run mmc_boot

bootcount=1

bootdelay=1

console=ttymxc0

cpu=armv8

distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done

efi_dtb_prefixes=/ /dtb/ /dtb/current/

ethact=ethernet@30be0000

ethaddr=00:14:2d:83:52:54

ethprime=eth0

fdt_addr_r=0x50200000

fdt_board=ivy

fdtcontroladdr=bdefa7b0

fdtfile=imx8mm-verdin-nonwifi-ivy.dtb

initrd_addr=0x43800000

initrd_high=0xffffffffffffffff

kernel_addr_r=0x48200000

kernel_comp_addr_r=0x40200000

kernel_comp_size=0x08000000

load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}

loadaddr=0x48200000

mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi

preboot=test -n ${fdtfile} || setenv fdtfile imx8mm-verdin-${variant}-${fdt_board}.dtb

ramdisk_addr_r=0x50300000

scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}…; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;

scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then part uuid ${devtype} ${devnum}:${distro_bootpart} distro_bootpart_uuid ; run scan_dev_for_boot; fi; done; setenv devplist

scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing…; fi; setenv efi_fdtfile

scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo EXTLINUX FAILED: continuing…; fi

scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing…; fi; done

scriptaddr=0x50280000

serial#=08606292

soc=imx8m

stderr=serial@30860000

stdin=serial@30860000

stdout=serial@30860000

update_uboot=askenv confirm Did you load flash.bin (y/N)?; if test “$confirm” = “y”; then setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200; mmc dev 0 1; mmc write ${loadaddr} 0x2 ${blkcnt}; fi

usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

usb_ignorelist=0x1050:*,

variant=nonwifi

vendor=toradex

ver=U-Boot 2024.07-7.4.0+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)

Hello @signo_ri,

I was double-checking this issue as you mentioned that you have an Ivy V1.0, but the screenshot is from the Ivy V1.1 schematics.

The component to check is still U16, which is in basically the same position on the two boards.
However, it is somewhat hard to check these signals without shorting multiple pins.
Such a short would explain a voltage level of around 1.1V.
Are you sure this was not a measurement error?

Do the actual RS232 and RS485 signals after the transceivers function at all?

Best Regards,
Bruno

Hi Bruno, i have downloaded the Ivy V1.0 schematic, but translators schematic page it seems to me the same as per 1.1.

I confirm that i have an high voltage level of 1,1V on all 4 signals, pin 2 to 5 of U16 and always 0V on the outputs of U16 pins 17 to 20 because U16 input cannot reach the minimum voltage level.

The signals are fine, i can change RTS polarity, and send bytes over TX on both serial ports Uart 1 and Uart2 but with 0 to 1,1V swing level. Otherwise Uart3 works correctly 0 to 1,8V.

If there is a short, it seems to me strange that it involves all 4 signals, maybe a failure in U16…

On January we will buy a new Ivy and a new Verdin, to check if the new one will works fine or reproduce the same issue.

Hello @signo_ri,

Thanks for the clarification.
It does looks like it could be a defect on U16.

Just to be clear that buying a board is not the only option, if you want, you could also submit an RMA for the Ivy board: Return Material Authorization (RMA)

However, you would be without your Ivy board for some time while we look into it.
It is also likely that this will only take place in 2026, as there are not many business days left in the year.

Best Regards,
Bruno

Dear Support, we bougth a new ivy plus v. 1.1A carrier board and a new Verdin imx8 MM 2GB V1.1D and now both Serial port 1 and 2 work correctly.

So the issue involve the ivy plus v.1.0A the is not working with both Verdin imx8 we have.

It is possible to submit an RMA for the Ivy board 1.0 and asking for a new one or better a 1.1A model?

Hi @signo_ri,

Thanks for the update.

Please do submit an RMA via the website: Return Material Authorization (RMA)

Functionality of UART2 and UART3 should be present on Ivy V1.0A, so it does look like a defect.
The usual process is that we provide a repaired or replacement board.

Depending on availability, it may be suitable to send a newer board instead, so please state that this would be an acceptable solution on your RMA request.

Best Regards,
Bruno

RMA sent.

For sure a new board is acceptable, better if new one is ivy plus v. 1.1A instead of 1.0A, just to have 2 boards of the same HW release.

Best

1 Like