RPi 4B fails to boot when two specific USB serial devices are connected

[psych0d0g]

Hardware and Power Configuration

• Pi Model: Raspberry Pi 4 Model B, 2GB
• Power: Powered by a dedicated 5V 3A PSU via the GPIO 5V and GND pins.
• USB Device 1: Duet 2 Controller, running Klipper firmware.
• USB Device 2: Fysetc H36 Combo Board, running Klipper firmware.

Both controller boards are powered by a separate 24V PSU that shares a common ground with the Pi's 5V PSU. The USB connections are for data transfer only.

Problem Description

The Raspberry Pi 4 fails to boot when both the Duet 2 and Fysetc H36 boards are connected to the USB ports. This failure occurs on both cold starts and reboots, with no signs of boot activity (e.g., no LED flashes, no HDMI signal).
When this happens not even the rainbow screen is showing up.

The boot process succeeds normally if either one of the two USB devices is disconnected. The disconnected device can be plugged back in immediately after boot starts, and both devices are then recognized and function correctly within the operating system.

Troubleshooting Steps Completed

1. EEPROM Firmware Verified: The bootloader is confirmed to be the latest version available (May 8 2025) via rpi-eeprom-update.
2. USB Port Isolation Tested: The failure persists regardless of how the devices are connected to the Pi's USB ports. The result is the same whether they share the same USB controller (e.g., both on USB 2.0) or are split between the USB 2.0 and USB 3.0 controllers.

Successful Workaround

The issue is reliably resolved by connecting both controller boards to the Pi through a simple, unpowered USB 2.0 hub. This suggests the problem is a boot-time USB enumeration conflict in the Pi's firmware.

[timg236]

Is the green LED on in the stuck state and do you get uart output if you set BOOt_UART=1 ?

[timg236]

To disable any form of USB enumeration set NETWORK_INSTALL_ENABLED=0 although this doesn’t sound related to firmware activity. If it was you would see errors on the HDMI diagnostic screen

[pelwell]

This sounds like an electrical problem - too much back-powering or current draw, perhaps. Do you have a USB hub you can interpose between the Pi and device (for diagnostic purposes)?

[psych0d0g]

Is the green LED on in the stuck state and do you get uart output if you set BOOt_UART=1 ?

no, the green LED does nothing when the stuck scenario is happening, just the red is permanently on.
setting BOOT_UART=1 makes no difference at all,
the attached HDMI screen dosnt even show the rainbow screen when the pi is "stuck" from booting

[psych0d0g]

This sounds like an electrical problem - too much back-powering or current draw, perhaps. Do you have a USB hub you can interpose between the Pi and device (for diagnostic purposes)?

as written in my initial report, plugging in a unpowered USB hub and connecting both boards via that one works around the issue, and the pi successfully boots.

the h36 does not even have its power line connected to USB, just both data lines and GND, and even if i pull that when the boot is stuck, it "solves" the issue temporarily, until the next reboot, so current draw can not really be the issue, neither back-powering, since the VCC line in this USB plug is not existing at all ;)

i can also add a touchscreen, powered via USB to HDMI, and a USB keyboard powered via usb which both draw power aswell to the pi, its just those 2 devices that block boot when connected directly to the pi at boot time

[psych0d0g]

NETWORK_INSTALL_ENABLED=0

you might be right, setting this does not change a thing either, what the?
even with both parameter set in eeprom, i wont even get to the rainbow-screen stage until i unplug one of the klipper controllers shortly

[timg236]

If NETWORK_INSTALLED_ENABLE=0 then the firmware will not attempt to search for USB keyboards for network install.

However, in this case, it looks the PMIC is detecting a back power issue and will not start. This isn't the current load it's the voltage levels. Hardware engineers on the Raspberry Pi forums might be offer advice if you post a high level schematic there.

We can see this because there is no activity on the green led or the UART. The firmware switches on the green LED and outputs a version message on the UART immediately after the bootrom starts it. This is before SDRAM and PCIe init so if neither of these are working then the bootrom hasn't started the firmware.

[psych0d0g]

interesting, back-power is pysically not possible tho, both usb cables used dont have their VCC / + lines connected, so power can not flow through them in either direction, only data and GND are there physically, i did create a forum post as suggested, i assume this issue is off-topic for the firmware project than and probably can be closed.
will continue here: https://forums.raspberrypi.com/viewtopic.php?t=391244