What this decides
Whether a USB MIDI controller works on a P4 board whose sockets sit behind a hub — which is most of them, the DEV-KIT's four Type-A ports included. USB MIDI is a full-speed class, and that is exactly the case the host stack does not cover today.
This is split out of #3 because #3's title and body are about the root port never reporting an attach, and that has been root-caused. The hub question is a separate capability with its own experiment, and right now it is invisible to anyone scanning issue titles.
The gap is the translator, not the hub
Worth stating carefully, because the two get conflated. Hub support is present and works. CONFIG_USB_HOST_HUBS_SUPPORTED and CONFIG_USB_HOST_HUB_MULTI_LEVEL are both set, those are the options Espressif's docs say enable it, and hubs enumerate.
The gap is one layer down. From the current esp-usb host guide, under the External Hub Driver's limitations, still verbatim today:
No Transaction Translator layer (No FS/LS Devices support when a Hub is attached to HS Host).
A high-speed root port talking to a hub needs that hub to split transactions for anything slower behind it, and split transactions are what is not implemented. So the failing combination is narrow and specific: full- or low-speed device, behind a hub, on a high-speed root port. High-speed devices behind a hub are fine. Anything behind a hub on a full-speed root port is fine, which is why the same hub carries everything on the S3 — there the root port is full speed, the hub links at full speed, and no translation is ever involved.
The experiment
Designed in #3's comments and not yet run. The DWC core has an FS/LS-only host mode: the host never chirps, the port comes up at full speed, and a USB 2.0 hub links at full speed exactly as it does on the S3, so full- and low-speed devices behind it need no translator.
The pinned LL already exposes it as usb_dwc_ll_hcfg_set_fsls_supp_only (hal/esp32p4/include/hal/usb_dwc_ll.h:447, per #3) and nothing in the HAL or HCD calls it, so it starts as a raw-register experiment:
host_start(), with nothing attached yet — the block is clock-gated before that and a read reboots the board.- Set bit 2 of
HCFG at 0x50000400.
- Plug in a hub with a full-speed device behind it.
- Watch
HPRT.prtspd — expect 1, full speed — and host_devices().
Run it on a board that sources VBUS toward its A sockets (the DEV-KIT's jumper is a real VBUS switch, unlike the 4B's sink wiring) or inject 5 V on the A side, per #3.
What each outcome means
If it works, it becomes a host_start() option: the S3's behaviour on the P4, at the cost of high speed for that session. A MIDI keyboard or a HID controller does not need high speed; a webcam does, which is why this is an option rather than a default. It also widens the board choice, because a hub-based P4 stops being disqualified for MIDI work.
If it does not, the P4's UTMI PHY does not honour the bit, and hosting full-speed devices on the P4 means a direct root port with nothing in between. That is a hardware-selection constraint and belongs in the board notes, because it quietly rules out a whole class of dev kits for anything MIDI.
Either way the answer is worth having written down before a board gets chosen for a build.
Related: #3 (where the experiment was designed, and the VBUS conditions it needs), #2 (host FIFO bias at runtime).
Generated by Claude Code
What this decides
Whether a USB MIDI controller works on a P4 board whose sockets sit behind a hub — which is most of them, the DEV-KIT's four Type-A ports included. USB MIDI is a full-speed class, and that is exactly the case the host stack does not cover today.
This is split out of #3 because #3's title and body are about the root port never reporting an attach, and that has been root-caused. The hub question is a separate capability with its own experiment, and right now it is invisible to anyone scanning issue titles.
The gap is the translator, not the hub
Worth stating carefully, because the two get conflated. Hub support is present and works.
CONFIG_USB_HOST_HUBS_SUPPORTEDandCONFIG_USB_HOST_HUB_MULTI_LEVELare both set, those are the options Espressif's docs say enable it, and hubs enumerate.The gap is one layer down. From the current esp-usb host guide, under the External Hub Driver's limitations, still verbatim today:
A high-speed root port talking to a hub needs that hub to split transactions for anything slower behind it, and split transactions are what is not implemented. So the failing combination is narrow and specific: full- or low-speed device, behind a hub, on a high-speed root port. High-speed devices behind a hub are fine. Anything behind a hub on a full-speed root port is fine, which is why the same hub carries everything on the S3 — there the root port is full speed, the hub links at full speed, and no translation is ever involved.
The experiment
Designed in #3's comments and not yet run. The DWC core has an FS/LS-only host mode: the host never chirps, the port comes up at full speed, and a USB 2.0 hub links at full speed exactly as it does on the S3, so full- and low-speed devices behind it need no translator.
The pinned LL already exposes it as
usb_dwc_ll_hcfg_set_fsls_supp_only(hal/esp32p4/include/hal/usb_dwc_ll.h:447, per #3) and nothing in the HAL or HCD calls it, so it starts as a raw-register experiment:host_start(), with nothing attached yet — the block is clock-gated before that and a read reboots the board.HCFGat0x50000400.HPRT.prtspd— expect 1, full speed — andhost_devices().Run it on a board that sources VBUS toward its A sockets (the DEV-KIT's jumper is a real VBUS switch, unlike the 4B's sink wiring) or inject 5 V on the A side, per #3.
What each outcome means
If it works, it becomes a
host_start()option: the S3's behaviour on the P4, at the cost of high speed for that session. A MIDI keyboard or a HID controller does not need high speed; a webcam does, which is why this is an option rather than a default. It also widens the board choice, because a hub-based P4 stops being disqualified for MIDI work.If it does not, the P4's UTMI PHY does not honour the bit, and hosting full-speed devices on the P4 means a direct root port with nothing in between. That is a hardware-selection constraint and belongs in the board notes, because it quietly rules out a whole class of dev kits for anything MIDI.
Either way the answer is worth having written down before a board gets chosen for a build.
Related: #3 (where the experiment was designed, and the VBUS conditions it needs), #2 (host FIFO bias at runtime).
Generated by Claude Code