UART2 Issue at boot

I built a system that uses both UART1 and UART2 for remote control and troubleshooting of devices. The entire system works fine except that I can’t boot the Rock Pi E with a 40 cm cable plugged into UART2 (only connect to GND, Tx, Rx on the RockPiE; the other end of the cable is floating).

I did some troubleshooting and I suspect that since UART2 is also used in the bootloader to interupt the boot process, I suspect that this floating Tx cable causes issues and interrupts the boot process.

I tried changing the bootdelay to 0 using
setenv bootdelay 0
saveenv

But I get an error that the MMC didn’t respond to voltage change command.

So… is there another way to modify this bootdelay to try to see if it resolves my issue?

I connected a console to the Tx pin and Gnd only while leaving my floating cable on the Rx pin. This way, I was able to confirm what happens, the bootloader gets interupted during the boot process.

Is there a way to disable the U-boot UART? I tried rebuilding u-boot by setting “CONFIG_DEBUG_UART=n” in rock-pi-e-rk3328_defconfig but that didn’t seem to work.

I will leave it here as it may help someone else but I answered myself.

By setting the bootdelay to “-2”, interupting u-boot is disabled so the board boots correctly. It still requires rebuilding u-boot from source to make this change but it’s at least feasible.

~/rockchip-bsp$ grep BOOTDELAY u-boot/configs/rock-pi-e-rk3328_defconfig
CONFIG_BOOTDELAY=-2

If you see the U-Boot boot log, you will find that bootloader can be stopped by hitting any key.

Hit any key to stop autoboot:  0

You have mentioned that a 40 cm cable. And you suspect that the floating Tx cable interrupts the boot process. What does it look like?

The problem is when there is a floating cable on Rx.

I was able to see it by connecting a console to TX and GND only. That way I saw the regular output and the bootloader being interrupted by some random characters appearing. By setting the boots slay to -2, it prevents interrupting u-boot and all is good.

In my scenario I had a floating cable on UART2, acting a bit like an antenna but the same problem would occur if UART2 was connected to a peripheral always transmitting, a GPS for example. In that case, rebooting the Rock Pi E would stop the bootloader from proceeding.

1 Like