DBG_CTRL and unexpected board shutdown

I have Verdin Development Board V 1.1B and Verdin iMX8M-Plus with installed TorizonCore.
I connected an USB-C cable to X66 connector to my Windows 10 PC so that I can see the 4 COM ports, as explained in the Section 2.21 ( USB Debugger) of the Verdin Development Board Datasheet.
No problem from this side; everything works as expected.

But I noticed that if I plug or unplug an USB device (even a pendrive) from another USB port of my PC, the Verdin Development Bord is immediately powered off.
I thought to the 4xGPIO pins used for performing basic Development Board control features: Power ON/OFF, Reset, …
This is the reason, because if I remove the jumpers 16, 17, 18 and 19 from X6 (disconnecting FTDI_GPIOLx from DBG_xxxx) the shutdown never appears.

Is this a known behavior?
Is this specific to my setup?

Hello @vix ,

yes, this is a known issue. The USB too UART chip cause the reset on the connected reset lines.
On the newer boards, we program the FTDI chip so that only 2 UARTS show up and the rest is configured as GPIOs.

Best Regards,

Matthias

Hi @matthias.tx

only to be sure that I was able to explain what I see.
I see the board shutdown when I plug an USB pendrive into another USB port of my laptop.
It seems that when the PC must deliver power to the new device, sometinh happens on all the USB ports (a short undervoltage?) and this produces the reset of the lines behind FTDI chip.

Have you already experienced something similar?
Or should I investigate on my laptop? Maybe the USB system is faulty.

Hello @vix,

that is what we see as well. Since the chip is still configured as for UARTS it does some undefined bit fliping during power up.
So nothing wrong with your computer.

Best Regards,

Matthias

@matthias.tx Is there any way to apply this same programming to older boards as well? I’m looking to use the FTDI gpio pins and it seems it would be easier if the FTDI chip would be configured in gpio mode by default, so the kernel GPIO drivers can be used to control these gpio pins. Also, I would like to prevent issues with accidental reboots (though I am not seeing such issues currently).

Oh, it seems that is not currently possible - the FT4232H used by the Verdin dev board is not supported by the kernel FTDI GPIO driver. Oh well, will have to try userspace control, then.

hi @matthijs,

yes, right now we have no driver for the GPIOs right now to control the pins. We programmed the new board as two URATS and the rest GPIO so that we do not get accidental triggers.

Best Regards,

Matthias