Can a board be USB host and USB device at the same time? Nothing records an answer

[claude]

What this decides

Whether a pedal can host a USB MIDI controller while still presenting itself to a PC — REPL, sound card, MIDI, or a drive for patch files — on a second connector. That combination is a stated board-selection requirement, and it is the only one of the three that is currently unrecorded anywhere. The other two (an ESP32-P4, readily available) are decidable from a product page.

Right now nobody can look this up. It came up in conversation, it got a plausible answer, and it was never settled or written down.

What we actually know

The pins don't collide on the P4. CONFIG_SOC_USB_OTG_PERIPH_NUM=2 is recorded in #3 from a built sdkconfig, and #3's bench notes place the second USB on USB_IN1_P/N (GPIO24/25) going to a header, separate from the HS OTG port that was under test. USB Serial/JTAG is a third block again. So the structural precondition holds: there are enough independent peripherals for the two roles to sit on different ones.

That is not the same as the stack supporting it. The precondition being met says nothing about whether usb_host_install() and the TinyUSB device stack can be up in the same firmware, on different peripherals, at the same time. I could not find an Espressif statement either way. Nothing in this repo claims it, and nothing here has ever run it.

The ESP32-S3 recollection needs checking before it's relied on. The belief that an S3 has done both at once may be a memory of something else, because the closest thing this repo records is not dual-role:

• The flagship demo in the README — one board on one cable being simultaneously the MIDI keyboard driving a DAW and the sound card playing its output — is two device functions in one composite costume. Both are device role. Impressive and real; not this.
• ESP32-P4 high-speed host detects no device; device mode on the same port works #3 records the opposite shape on the P4: device mode works on the HS OTG port, host mode never sees an attach on it.
• S3 native USB port sees no attach — blocks Device MIDI IN (M3's last quadrant) #1 records the S3's native port failing to present as a device at all, intermittently.

If the S3 really did run host and device concurrently, it would have been on the one OTG peripheral plus USB Serial/JTAG, and on the S3 those share pins — which is the usual reason only one works at a time. That deserves a check rather than an assumption in either direction.

The experiment

Cheap, and it needs no new hardware beyond a board with two usable USB connectors.

1. host_start() on the port wired for host, with a full-speed device attached, and confirm an attach in host_stats().
2. With the host still running, bring the device side up — bare CDC is enough — on the other peripheral.
3. Check both directions still work: the host still reports its device, and the PC still sees the CDC.
4. Then reverse the order — device first, host second — because a stack that tolerates one order may not tolerate the other.
5. Record which peripheral carried which role, and the FIFO bias in force (Choose the host FIFO bias at runtime, not at build time #2), since the host side's channel and FIFO budget is per-controller and this doubles the demand on whatever is shared.

What each outcome means

If it works, the pedal can host its own controller and still be a sound card and a REPL to a PC, and the board requirement is satisfiable. It should become a documented capability with the pin and peripheral assignment spelled out, because it constrains which dev kits qualify.

If it doesn't, a pedal has to choose per session, or use a second chip for the control surface. That is a product-shape decision, not a firmware detail, and it wants to be known before a board is picked rather than after.

Related: #3 (the P4 HS host defect, and where the peripheral count is recorded), #15 (full-speed devices behind a hub, the other half of whether a MIDI controller works at all), #2 (host FIFO bias, which this would put under more pressure), #1 (the S3 device-side attach failure).

---

Generated by Claude Code

[bdbarnett]

Still unanswered on 1.29. Nothing in the tree has run host and device at once.

It needs two usable USB ports, and neither bench board has them. On the S3, OTG and Serial/JTAG share one pin pair. On the P4 4B, the second controller's pins (GPIO24/25) reach header P2 through unpopulated series resistors (#3), and the HS port can't host without 5 V injected.

@bdbarnett, one question: should this wait for a board with two real USB ports, or do you want to fit those two resistors on the 4B and wire a socket to P2?

[bdbarnett]

Brad's decision (2026-09-26): parked, waiting for a board with two real USB ports. No resistors on the 4B. The trigger is a bench board whose host and device ports are both usable without fabrication.