S3 native USB port sees no attach — blocks Device MIDI IN (M3's last quadrant)

[bdbarnett]

Blocks: Device MIDI IN — the last open quadrant of milestone M3. The test
is written and proven (examples/midi_device_in.py, 6d247d9); it stops at the
mount wait because the board never appears to the PC.

Symptom

The ESP32-S3's native USB port presents nothing to the host. Reproduced twice,
independently, under the protocol a previous session prescribed (probe --reboot-first, run never exec, nothing else touching the board), on the
most-proven costume:

built 0x1f pid 0x4003
costume cdc only, pid now 0x4001
    0 ms  connected=False mounted=False suspended=False
final (False, False, False)

connected is TinyUSB's bus-reset flag. It never goes true across a 15 s poll.

Both ends agree, and they agree on never saw an attach

• Board: connected=False. No bus reset, which is below any driver binding.
• Board: host stack not running (host_stats()[0] false), so this is not
  the OTG PHY being held in host mode.
• Windows: enumerates only the CH343 UART bridge (COM49).
• Windows: zero USB devices in a non-OK state, zero problem codes.
  A descriptor-request failure or a driver-bind failure would each leave an
  error node. There is none — so the PC is not failing an enumeration, it
  never sees an attach at all.

What is ruled out

The board, its jack, its PHY routing, and this firmware family — all cleared.
The board's unique_id is 30:30:f9:0f:6a:a4, and Windows holds cached device
nodes for that exact id, on that native port, in four forms:

Cached node	What it was
USB\VID_303A&PID_1001\30:30:F9:0F:6A:A4	USB-Serial-JTAG
USB\VID_303A&PID_4001\3030F90F6AA40000	usbif bare CDC
USB\VID_303A&PID_4003\3030F90F6AA40000	usbif CDC+MSC composite
USBSTOR\DISK&VEN_MICROPY&PROD_MASS_STORAGE... + SWD\WPDBUSENUM\...D:\	the MSC drive, mounted as D:

PID_4001 is the exact bare-CDC costume the probe above fails on. Same board,
same costume, same PC, previously enumerated. This closes off the whole class of
"this hardware path was never going to work," which is where an intermittent
fault usually hides.

Host-mode rig configuration — ruled out. The bench had been wired for host
work (powered hub on an OTG adapter on the native port, with a MIDI keyboard,
a wireless dongle and a flash drive behind it), which would explain
connected=False completely. That cable swap has since been done, and the hub's
peripherals are absent from Windows too, consistent with the rig being unplugged
rather than moved.

The PID-cache collision — real, but not this. Windows holds 115 cached
VID_303A nodes, and under PID_4003 there are two different boards
(container ids matching the P4's MAC and this S3's), each cached as a CDC+MSC
composite. That is exactly the collision TinyUSB's header warns about and is
worth clearing before the VID move to 0x4CD3 — but bare CDC enumerates as
0x4001, a different cached identity, with the same result. Driver-bind failure
and never-seeing-a-host are different layers.

What is left

1. The cable now in that jack.
2. The PC port it is in.
3. PC-side USB stack state.

The fault is intermittent — the PID_4003 node above is almost certainly a
single brief success on 2026-08-31 that "reverted within seconds" and was never
reproduced. Intermittency argues a marginal connection over a misconfiguration.
This is deliberately not a cable accusation: the evidence narrows to the
physical path without identifying which element.

Next steps

• The PC reboot, still unrun. It was queued on 2026-08-31 and the session
  that queued it ended; Windows LastBootUpTime is 2026-08-31 03:27 (uptime
  1d13h at capture), spanning the entire pause. It tests candidate 3 directly
  and is the only candidate that costs nothing.
• The two-move physical discriminator, which splits the other two: a
  known-good device on the same cable and same port; then the S3's native jack
  on a different port with a different cable.
• Capture state either side of whichever is tried. If the reboot clears it,
  the fault is fixed without learning which of the three it was, and a marginal
  connection will recur. A pre-reboot baseline is attached below so a recurrence
  has something to diff against instead of restarting this hunt.

Pre-reboot baseline

Captured 2026-09-01 16:50 local, fault live.

LastBootUpTime      08/31/2026 03:27:05
present USB devices 8 (2x ROOT_HUB30, webcam 04F2:B7CE x4 nodes,
                       06CB:0106, CH343 1A86:55D3, 8087:0033)
USB host controllers 2x Intel USB 3.20 eXtensible (7E7D, 7EC0)
USB root hubs        2 (no Generic USB Hub present - the powered hub is out)
cached 303A/4CD3     115 nodes
non-OK USB devices   0
board                unique_id 30:30:f9:0f:6a:a4, MicroPython 1.28.0,
                     ESP32_GENERIC_S3-SPIRAM_OCT, dev_functions_built 0x1f,
                     costume_selftest 31/31

[bdbarnett]

Correction: the framing above is wrong, and the archived transcript says why

Recovering the predecessor session's transcript changed this materially. Two
corrections and one clue that reframes the whole bug.

1. The port has enumerated as a device on this rig, and the fix was a cable swap

On 2026-09-01 at 00:07 UTC Brad swapped the two cables at the board — his own
test, run specifically to disprove agent cable-blaming. COM73 appeared with
303A:4003 SER=3030F90F6AA40000 and dev_state() read (True, True, False)
immediately.

But it did not hold. By 00:20 it was gone, and it never came back that night
through a cable swap-back, a full power cycle, a reflash, costume
simplification down to bare CDC, and a different PC port. Later sustained
(True, True, False) readings in that transcript are the P4, not this S3 —
the work moved boards at 01:08.

So "one brief success then it reverted" is right, but the earlier claim that no
bad cable was ever found is not the whole story: a swap did produce an
immediate, clean attach once.

2. The same port works fine in host mode — which no cable fault survives

Through 2026-09-01 this S3's native port ran host work all day: a powered
hub on an OTG adapter with a MIDI keyboard, a wireless dongle and a flash drive
behind it, and Host MIDI IN proven with 989 channel messages read and zero
dropped.

Same connector, same GPIO19/20, same PHY. A bad cable, a bad jack or a dead PC
port would break host mode too. It didn't. That largely clears the physical
path and makes this specifically a device-mode failure — which also weakens
the PC-reboot candidate below, since PC stack state cannot explain the board
succeeding as a host on that same connector.

3. Hypotheses tested and eliminated today

Hypothesis	Result
Rig still wired for host mode	Ruled out — the cable swap to the PC was done
USB/CAN mux on CH422G EXIO5 (high = CAN, expander powers up all-high)	Tested and eliminated. Drove EXIO5 both ways with the register readback confirming the write landed (wr_io 0xff→0xdf→0xff); no attach in 6 s at either polarity
Windows PID cache collision	Ruled out — bare CDC is PID_4001, a different cached identity, same failure
Board / jack / PHY routing / firmware family	Ruled out by the cached nodes above

The mux was a genuinely good hypothesis raised in the archived session and never
tested there — this board family really does mux CAN onto that connector via
EXIO5, and the expander really does power up with every output high. It simply
is not the cause.

4. Where this now points

The board sources VBUS successfully (host mode works) but never detects
it (device mode sees no bus reset). That is a specific seam, and
patches/0004-esp32-otg-phy-handoff-for-host-mode.patch sits directly on it —
it is named for host mode, and the question is whether the device side reliably
re-takes the PHY after this board has been in host mode, across a reset.

That reframes the next step away from the PC reboot and toward instrumenting
the device-side PHY/VBUS path. The reboot is no longer the cheapest useful test;
it cannot explain host mode working on the same connector.

5. Method note

Every probe in the original report used probe --reboot-first. If any candidate
turns out to be state established after boot, that flag would mask it. Worth
remembering when testing the PHY seam.

[bdbarnett]

Resolved to a measurement: VBUS is present, the data lines are not

Read the ESP32-S3 USB-OTG (DWC_OTG) core registers directly, with the fault
live and the board freshly booted:

dev_state (False, False, False)   functions 0x3
GOTGCTL  0x00090000   BSesVld=1  ASesVld=0  ConIDSts=1
GUSBCFG  0x40001447   ForceDevMode=1  ForceHstMode=0
GINTSTS  0x44008420   USBRst=0  EnumDone=0
DCTL     0x00000000   SftDiscon=0
DSTS     0x00400007   SuspSts=1

Read in plain terms:

Register bit	Says
GOTGCTL.BSesVld = 1	VBUS is present at the port. Something is powering it
GOTGCTL.ConIDSts = 1 / GUSBCFG.ForceDevMode = 1	correctly in device mode, not host
DCTL.SftDiscon = 0	the D+ pull-up is asserted — the board is presenting itself
GINTSTS.USBRst = 0, EnumDone = 0	the host has never issued a bus reset
DSTS.SuspSts = 1	so the device sits suspended

The board is doing everything right and the host is not answering. VBUS
arrives, the pull-up goes up, and nothing comes back. That is the signature of
a link that carries power but not data — a charge-only or damaged cable, a
connector with broken D+/D-, or a power-only port at the other end.

This supersedes the "three candidates" framing in the issue body and the
device-mode/PHY-handoff lead in the first comment. The PHY is configured
correctly; the OTG controller is in device mode with a valid session. Nothing
above the wire is wrong.

Why host mode still worked on the same connector

Host mode ran through a C-to-A OTG adapter into a powered hub — a different
physical link than the plain cable now in that jack. It exercised the board's
connector and PHY (both fine, as these registers confirm) but never this cable.
So the two observations are consistent, and the connector is cleared twice over.

The discriminator, which Brad already invented

Swap the two cables at the board. He ran exactly this at 00:07 UTC on
2026-09-01 and COM73 appeared immediately with dev_state() (True, True, False). If it attaches again, the fault travels with the cable; if it stays
dead while COM49 keeps working, the fault is the PC port. One move, either way.

Worth noting it is also worth confirming the native cable reaches the PC and
not a charger or a power-only hub port — a charger produces this exact register
signature.

Method note, corrected

The first comment's suggestion to instrument the PHY seam is withdrawn — the
registers answer it directly and the PHY is not at fault.

[bdbarnett]

Retraction: the "power but not data" conclusion is withdrawn, and the port is up

The previous comment concluded a bad cable from BSesVld=1 / SftDiscon=0 /
USBRst=0. That inference does not hold, and the register evidence does not
support it. Those bits are equally consistent with a dead data path and
with a host that simply is not answering a device it can already see. I read
one of two possibilities as the only one.

The port is now up. After Brad swapped the two cables: dev_state()
(True, True, False), Windows USB\VID_303A&PID_4003 Status OK with COM73
and the MSC interface, and on the pure-MIDI costume (PID_4008) it enumerates
as MEDIA-class "Espressif Device".

Why the swap still does not prove the cable

The S3 draws power from both ports, either one alone (Brad, and it changes
the meaning of every cable test in this issue):

• Swapping both cables power-cycles the board. That is two variables in
  one experiment — the cable and a full power cycle — and cannot attribute to
  either.
• Pulling only the OTG cable never power-cycled it. The UART cable kept
  it alive with all state intact. An entire night of "unplug the OTG cable and
  see" was re-seating a connector on a fully-powered board.
• The P4 is powered from its UART port only, so an OTG pull there is a
  clean data-only change. The right instrument differs per board.

Brad has also already run a full matrix against both cables currently in use —
each one alone, plugs flipped, ends swapped — and everything passed. The one
genuinely faulty cable in this project's history was found early and discarded.
Agents on this program have repeatedly blamed cables; this issue added to that
record and is correcting it.

No cable conclusion should be drawn again without an experiment that holds
power constant.

The instrument that does hold power constant

Toggling DCTL.SftDiscon (0x60080000 + 0x804, bit 1) is a genuine
host-visible unplug/replug — Brad heard Windows' disconnect and reconnect
chimes from a script with nobody touching the bench. It changes exactly one
variable and leaves power alone, and it re-triggers host enumeration when a
stale port state is suspected. Cycling it on a working link unmounts it;
dev_reinit() recovers immediately.

What is actually still unexplained

Not the cable: what makes the port die and stay dead across CPU resets until
a genuine power cycle. Every probe in this issue used probe --reboot-first,
which is a CPU reset, not a power cycle — so all of that testing sat inside the
dead regime and could never have observed the recovery. That is the open
question, and the power-topology fact above is why it stayed hidden.

[bdbarnett]

RESOLVED for the MIDI blocker — Device MIDI IN passes. Bench state recorded before a session restart.

Device MIDI IN is proven; M3 is complete

Driven from Windows winmm directly, with no DAW in the loop:

bytes read      123
note-on         9      note-off   9
cc              16     pitch-bend 7
channels seen   [1, 4]
velocities      8 distinct (min 1 max 127)
pitch bend      0 .. 16383
desync bytes    0
result          PASS

Exact match for what was sent. Full-range 14-bit bend reassembles correctly —
the one place a byte-order error is silently wrong rather than absent.

The first attempt read zero bytes and was not a usbif fault: REAPER's
routing simply wasn't sending. That false negative is the reason the test was
re-run from winmm directly, and the reason examples/midi_test_project/
now exists with routing already correct.

Bench state as of this writing — assume nothing else survives

The physical facts that no repo records, written here because exactly this
kind of state died with a previous session and cost a day:

• S3 REPL: COM49, the CH343 UART bridge. Unchanged all session.
• S3 native USB port: connected directly to the PC (no OTG adapter, no
  hub). Brad performed this cable swap himself between sessions.
• The powered hub, Donner keyboard, wireless dongle and SanDisk are
  UNPLUGGED — the host-mode rig from the previous session is dismantled.
• The board is left in the pure-MIDI costume, dev_functions() == 0x8,
  PID 0x4008, dev_state() == (True, True, False) — connected and
  mounted, enumerating on Windows as MEDIA-class "Espressif Device".
  This is deliberate and is NOT the state it was found in (0x3, CDC+MSC).
  It is left this way because the immediate next action is opening
  examples/midi_test_project/USBIF_MIDI_Test.RPP, which requires the MIDI
  costume. Restore with _usbif.dev_functions(_usbif.FN_CDC | _usbif.FN_MSC)
  if CDC/MSC is wanted back.
• Firmware: unchanged this session. MicroPython 1.28.0,
  ESP32_GENERIC_S3-SPIRAM_OCT, dev_functions_built() == 0x1f (all five),
  costume_selftest.py 31/31. Nothing was built or flashed.
• Board filesystem: boot.py, lib/, sd_msc_demo.py. No stray logs; every
  diagnostic file written this session was removed.
• REAPER: "Espressif Device" is MIDI output ID 1 and enabled; Microsoft GS
  Wavetable Synth is ID 0 and NOT enabled. Confirmed from a screenshot of
  Preferences → MIDI Outputs, so MIDIOUT 32 is fact rather than inference,
  and there is no path where a project silently plays the PC synth instead
  of the board.

What remains open on this issue

Not the cable, and not MIDI. What makes the port die and stay dead across
CPU resets until a genuine power cycle. It has not recurred since the swap.
Notes for whoever picks it up:

• probe --reboot-first is a CPU reset, not a power cycle, so every probe
  in this issue's history sat inside the dead regime and structurally could
  not observe recovery.
• The S3 draws power from either port, so pulling only the OTG cable never
  power-cycles it. The P4 is UART-powered only, where an OTG pull is a clean
  data-only change.
• The instrument that holds power constant is the D+ toggle:
  DCTL.SftDiscon at 0x60080000 + 0x804 bit 1 — a genuine host-visible
  unplug/replug, audible as Windows' disconnect/reconnect chimes, with nobody
  at the bench. Cycling it on a working link unmounts it; dev_reinit()
  recovers immediately.
• Companion reads that separate three identical-looking failures:
  GOTGCTL.BSesVld (VBUS actually present), DCTL.SftDiscon (are we
  presenting a pull-up), GINTSTS.USBRst (did the host ever reset us).

Do not conclude "bad cable" again without an experiment that holds power
constant. Both cables currently in use have already passed a full matrix —
each alone, plugs flipped, ends swapped — and the one genuinely faulty cable
in this project's history was found early and discarded.

[bdbarnett]

Bench state superseded — read this, not the previous comment

A full Windows reboot is being taken to clear a wedged MIDI subsystem. The
board state recorded in the previous comment is out of date; this is
current.

Board state at reboot

• Costume 0x3 (CDC+MSC), PID 0x4003. MIDI is OFF, deliberately.
  It should stay off through the reboot so MIDI is not a variable in the
  recovery. Restore with _usbif.dev_functions(_usbif.FN_MIDI) only after
  Windows is up and midiOutGetNumDevs is confirmed to return promptly.
• REPL on COM49 (CH343 UART bridge), native port on a plain cable direct
  to the PC. Firmware untouched all session. No stray files on the board.
• BeatBuddy unplugged. Host-mode rig (hub, Donner, dongle, SanDisk) dismantled.

The Windows MIDI subsystem is wedged kernel-side

midiOutGetNumDevs hangs in a brand-new process with zero third-party
MIDI devices attached. REAPER's "Scanning MIDI output devices..." hang is the
same block one layer up -- not a REAPER bug.

Every user-space explanation was eliminated by test, and none helped:

Suspect	Test	Result
Phantom MEDIA-class device nodes	pnputil /remove-device on all 15	still hangs
PowerShell stuck since 09:42pm	killed it	still hangs
Hung REAPER holding the stack	killed it	still hangs
BeatBuddy	unplugged	still hangs
Our board's MIDI function	disabled (0x3)	still hangs

Only a reboot clears this.

The trigger, recorded plainly because it was self-inflicted

Detaching the board with the D+ toggle (DCTL.SftDiscon) while REAPER was
mid-MIDI-enumeration wedged wdmaud. The toggle was written up earlier the
same day as a clean, hands-free replug; it is a genuine hard unplug and is
not safe unconditionally. Never use it while a host is scanning MIDI. When
only the MIDI function needs to go away, change costume with
dev_functions() instead of removing the whole device.

Two corrections to earlier comments on this issue

1. The phantom VID_303A nodes are not a problem and not a trap for the VID
   move. An earlier comment framed the accumulation as an uncounted cost of
   PID-per-costume. That is wrong: per-costume PIDs exist precisely so Windows
   caches each interface set separately and never confuses one for another
   under a reused PID. That is the design working. (Brad's correction.)
2. The BeatBuddy presents mass storage only -- Class_08&SubClass_06&Prot_50,
   single interface, Ven_TI, a 4 GB FAT32 volume. Its display reads "USB
   Device connected", i.e. SD-card storage mode. It exposes no USB MIDI
   interface in that mode, so it is the wrong instrument for a USB-MIDI test
   and the right one for testing host-side MIDI OUT over 5-pin DIN.

After the reboot, in order

1. Confirm midiOutGetNumDevs returns promptly (a few seconds, not a hang).
2. Launch REAPER bare and let it reach its main window.
3. Only then set the board to the MIDI costume, and rescan MIDI devices in
   REAPER's preferences if it does not appear.
4. Open usbif/examples/midi_test_project/USBIF_MIDI_Test.RPP.

M3 itself is unaffected and remains complete: Device MIDI IN passed with 123
bytes, 8 distinct velocities across 1..127, pitch bend reassembling 0..16383,
two channels, zero desync.

[bdbarnett]

Do not read a healthy machine after this reboot as evidence about the port fault

These are two separate faults and the reboot addresses only one of them:

1. The Windows MIDI subsystem wedge (this evening, self-inflicted by a D+
   detach during REAPER's MIDI enumeration). The reboot clears this. Expected.
2. The original die-and-stay-dead port fault — the S3's native port going
   dark and staying dark across CPU resets until a genuine power cycle. The
   reboot tells us nothing about this.

The trap is specific and easy to fall into, because a reboot was already
queued for this issue back on 2026-08-31 on the theory that PC-side USB stack
state was the cause. That theory was never tested and is still untested. If
the machine comes back up and the port behaves, it will be tempting to close
that as "the reboot fixed it, so it was PC stack state all along."

That inference does not hold. The reboot is being taken tonight for an
unrelated, fully-diagnosed reason. The port has been working since Brad's
cable swap hours before any of tonight's MIDI trouble began, so a working
port afterwards is the continuation of an already-working state, not a
recovery. Nothing about tonight discriminates between the candidates for the
original fault.

The die-and-stay-dead behaviour remains open, unexplained, and un-reproduced
since the swap. It needs an experiment that holds power constant -- and note
that the obvious instrument for that, the D+ toggle, now carries the warning
above and must not be used while a host is enumerating MIDI.

Credit where due: this distinction was caught by the Arthur session, not by
me, and it would have been a plausible and wrong conclusion for whoever picked
this up next.

[bdbarnett]

The MIDI wedge is CLEARED, and the diagnosis is confirmed end to end

A true cold boot (event 27, boot type 0x0, 2026-09-01 22:39:47) cleared
it. midiOutGetNumDevs now returns instantly, REAPER launches normally, and
with the board back on the MIDI costume it enumerates as Espressif Device at
output ID 1 — the same index the test project's MIDIOUT 32 expects, so
no rescan or fixup was needed.

The thing that nearly cost another hour: the first reboot was not a reboot

Brad shut the machine down and powered it back on. The wedge survived, and
LastBootUpTime still read 08/31 — so I told him the reboot had not happened.
He had rebooted; Windows had not. Fast Startup (HiberbootEnabled = 1) is
on, so "shut down + power on" is a hybrid boot: the kernel session is
hibernated and restored rather than rebuilt, and a kernel-state fault survives
it untouched. LastBootUpTime only tracks full boots, which is why it looked
like nothing had happened.

Verify a boot's type before concluding anything from it:

Get-WinEvent -FilterHashtable @{LogName='System'; ID=27} -MaxEvents 1
#  0x0 = cold boot    0x1 = hibernation resume (Fast Startup)    0x2 = sleep

Ask for Restart specifically, never "shut down and start it again" —
Restart always bypasses Fast Startup. shutdown /r /t 0 does too.

Confirmed by this, and worth stating plainly

The wedge was kernel-side, exactly as diagnosed. It survived every
user-space remedy (clearing 15 phantom device nodes, killing a stuck
PowerShell, killing the hung REAPER, unplugging all MIDI hardware, disabling
MIDI on our board) and a hybrid boot, and died only to a full one. That is
about as conclusive as this kind of thing gets.

The trigger stands as recorded: a D+ detach (DCTL.SftDiscon) fired while
REAPER was mid-MIDI-enumeration. Never toggle while a host is scanning MIDI.

One theory raised and disproven tonight, recorded so it does not resurface

When REAPER later showed "not responding" on close, I proposed that an
undrained device-side MIDI OUT endpoint was blocking the host — plausible,
since nothing on the board calls midi_read once a script ends. Tested and
false: a 25-second drain recovered 6 bytes. There was no backlog and no
stall. REAPER was simply slow to shut down, and recovered on its own. The
"undrained endpoint hangs the host" hypothesis has no evidence behind it and
should not be repeated without some.

Device MIDI IN, now proven a second way

With the real REAPER project playing (Canon in D, five tracks): 3950 bytes,
465 note-ons, 463 note-offs, 288 CCs, 96 pitch-bends, all 16 channels, zero
desync bytes. The canon voices are visible entering staggered on channels
1/2/3 over the ground bass on 4. The all-16-channel traffic is REAPER's
standard playback-start reset, not a fault.

[bdbarnett]

End of session 2026-09-02 — bench state, and two rows closed

Bench, as left

• S3 native port is in HOST mode: OTG adapter → powered hub → SanDisk
  Cruzer Glide + Donner keyboard. Not attached to the PC, so nothing of
  ours appears to Windows.
• REPL on COM49 (CH343 UART bridge).
• Device-side costume 0x3 (CDC+MSC), dev_functions_built() == 0x1f.
• Host stack stopped (host_stats()[0] false).
• Filesystem clean: boot.py, lib/ (ch422g.py, sdcard.mpy), sd_msc_demo.py.
  Every diagnostic log written this session was removed.
• Firmware rebuilt and flashed twice tonight — current image carries
  c2149f5 and 438bbcf. It is newer than any previously flashed build, so
  do not assume a stock image.
• Windows MIDI enumeration healthy since the cold boot; REAPER launches fine.

Closed this session

host_stop() → Done (438bbcf). Teardown's own event drain was delivering
queued NEW_DEV messages, opening a device after the close loop had passed
over it; deregister then refused and everything cascaded. Teardown now declines
new devices. deregister 0x103→0x0, ALL_FREE 1000 ms timeout→10 ms,
host_stop 1584→595 ms, 60/60 clean with sessions deliberately left open
and zero variance across the run. Polite path unregressed at 433–461 ms.

REQUEST SENSE → Done. No code change needed. The SanDisk rejects a bad
opcode with CSW status 1 and no stall, so sense is read while the device still
holds it: 0x05 ILLEGAL REQUEST / asc 0x20 INVALID COMMAND OPERATION CODE.
The old NO SENSE result was device behaviour — stall-rejecting drives force
Reset Recovery, which clears sense first.

M3 → complete, including its verification line: four quadrants, both
directions, timing measured (median 5 ms round trip, 50/50 returned).

Corrections that must not be un-made

• c2149f5 is not the host_stop cure. Its honest-uninstall-error half
  earned its place (it turned a silent failure loud, which is what made the
  diagnosis possible); its MSC teardown variant may be doing nothing. Not
  claimed either way.
• The bad-cable conclusion is retracted. The S3 draws power from either
  port, so swapping both cables is also a power cycle — never a one-variable
  test. Both current cables have passed a full matrix.
• The undrained-endpoint theory is disproved: 6 bytes recovered in a 25 s
  drain. No backlog, no stall.

The trap that nearly cost a correct fix

A probe errored before running and left the previous /hs.log on the
board. It showed the old failure verbatim and read as a fresh result — enough
to discard a fix that was actually working. What caught it was deleting the log
before re-running and checking for the new firmware's own printf.

Same shape as host_msc_diag() being sticky (one step reporting the previous
step's sense as an independent pass), and as the stale rig and reboot notes
earlier. Delete the artifact before re-running; confirm a fresh marker before
believing it. This is the signature failure mode of this bench.

Still open

Phase 3 items 2, 4, 5 untouched; item 3 part-built (portable MIDI contract
landed in pydevices 92416a1, winmm/ALSA backends not written).
Mostly remaining: SD-card format across the link (needs device mode, so it
conflicts with the current host rig) and macOS (needs hardware that does not
exist here).

[bdbarnett]

M5 complete — both directions verified on hardware.

The S3 now captures from a hosted USB microphone and drives a hosted USB CODEC. Both blessed by ear: capture against Brad's voice earlier, playback as a seven-note arpeggio out of the monitors.

Root cause of the isochronous panics (usbif 95650bc). Playback panicked every time — StoreProhibited in TLSF's remove_free_block(), later LoadProhibited in IDF's handle_ep0_dequeue() — always inside an allocation with nothing to do with USB. Capture on identical firmware was clean, which made it look like an OUT-path bug. It was not.

This port runs at CONFIG_FREERTOS_HZ=100, so one tick is 10 ms and pdMS_TO_TICKS(5) truncates to zero. vTaskDelay(0) does not block — it yields to equal-priority tasks and returns. So:

for (int i = 0; i < 100 && !done; i++) vTaskDelay(pdMS_TO_TICKS(5));

is not a 500 ms wait. It is 100 non-yielding iterations completing in microseconds, while the host task — the only thing that can deliver the completion callback — never runs. The control transfer was then declared failed and freed while the USB host library still owned it. The panic landed wherever the heap was next touched.

usbif_host.c already carried a comment noting pdMS_TO_TICKS(5) is zero ticks here. Found once, never audited across the module. Three more sites had it, including the close drain that frees isochronous buffers after waiting. All now use USBIF_DELAY_TICKS(), which never rounds below one tick.

Two further real defects fixed on the way:

• Client-handle serialisation. The host task pumps library and client events (which run enumeration) while the MicroPython thread independently calls usb_host_interface_claim() and usb_host_transfer_alloc() on the same client. A recursive mutex now guards both pumps and every public open/close/read/write. Every completion wait suspends it first — the callback comes from the task the lock excludes, so holding it across a wait is a guaranteed deadlock, not merely slow.
• Transfer ownership. usbif_uac_control() freed its transfer on every path including submit failure and timeout. It now frees only when the callback has actually fired, matched by pointer so a late callback cannot mark a later transfer done. A genuine timeout leaks eight bytes rather than corrupt the heap.

Evidence. Playback opens and streams clean 4/4 with no settling delay (the workaround previously needed): 6616 packets, 0 dropped, 0 errors, clean close. Capture unregressed at 3014 packets, 0 dropped. The scripted A/B that proved the diagnosis: removing the diagnostic printf from the wait loop brought the failure straight back 3/3 — the printf had been the only thing letting the host task run.

Also fixed in cmods (unpushed): 3f9c51e raises the S3's control-transfer buffer to 4096 (the monitors' 1191-byte descriptor was invisible at the 256-byte default; also a UVC prerequisite) and biases the DWC FIFO for periodic OUT (192 → 600 bytes per isochronous OUT packet). 36f8029 adds the JTAG variant's missing flash-size fragment — its partition CSV is sized for 8 MB but had no .sdkconfig fragment, so it had never been built clean; it only ever worked against a build directory already carrying 8 MB from earlier state.

Bench state: S3 on COM49, UART only for the REPL, powered hub on the OTG port with the Burr-Brown CODEC (monitors) and C-Media mic behind it. Firmware is ESP32_GENERIC_S3 / SPIRAM_OCT_JTAG, which requires micropython-pydevices patch 0009 applied to cmods/micropython — the tree had been re-synced to stock and lost it.

Open: Phase 6 (UVC) — camera received, not yet on the bench. Gates 4–5 unpresented. VID move pending.

[bdbarnett]

Phase 6 first light: the S3 is capturing video from a USB camera.

A Logitech C920e on the powered hub, enumerated by the board, mode negotiated by the board, frames assembled by the board. The first frame decodes as a baseline JPEG, 320x240, 3 components, 8064 bytes.

usbif_uvc: negotiated fmt 2 frame 6 -> payload 384, frame 153600 bytes
usbif_uvc: interface_claim(itf=1 alt=2) -> 0x0
usbif_uvc: SET_INTERFACE(1, 2) -> 0
frames seen: 11
stats (frames,packets,bytes,full,torn,big,errors,empty): (11, 181, 63804, 0, 0, 0, 0, 1651)

Zero dropped, zero torn, zero oversized, zero bus errors.

The camera offers a full-speed configuration, which is what made this possible on the S3 at all. Its high-speed blob is 2306 bytes and advertises modes up to 1920x1080; at full speed it presents a different, 1038-byte configuration — still MJPEG up to 640x480 @ 30 fps, with six bandwidth tiers from 192 to 944 bytes.

PROBE/COMMIT works and the camera really does scale its payload to the mode. Swept across modes, its answers were:

Mode	Negotiated payload
160x120 @ 5	192
160x120 @ 10	192
160x120 @ 30	512
320x240 @ 5	384
320x240 @ 10	640
320x240 @ 15	944
640x480 @ 5	944
640x480 @ 30	944

This is the concrete vindication of splitting choose() from alt_for_payload() on the Python side. A host that computed bandwidth from dwMaxVideoFrameBufferSize would have demanded 4608 bytes/ms for the 320x240 @ 5 fps mode the camera actually serves in 384.

The FIFO bias is a genuine board-wide conflict, now filed as #2. Claiming the camera's endpoint failed with ESP_ERR_NOT_SUPPORTED until the DWC FIFO bias moved from periodic-OUT (added this morning for audio playback, IN capped at 128) to IN (600). The cost is real: hosted audio playback keeps 48 kHz mono and loses 48 kHz stereo, both of which were demonstrated working earlier today. usb_host_config_t.fifo_settings_custom allows choosing this at runtime from the classes host_start() was given, which would remove the trade entirely.

Note the failure mode: a wrong FIFO bias surfaces only as a claim failure carrying no information about packet sizes. It cost real time twice today, in both directions.

Still open for Phase 6: the P4's high-speed host, where the interesting resolutions live. Its host mode has never detected a connection (findings, Phase 0/1) and the HS test devices that were "in the post" then have now arrived, so it is worth retesting — starting with a device the S3 already hosts cleanly, so that "does the P4 host work at all" is separated from "does the UVC driver work".

[bdbarnett]

Audit 2026-09-04: the blocking claim is stale; the port fault is not.

The title and the "Blocks" line no longer hold. All four M3 quadrants closed on 2026-09-01, Device MIDI IN included — 123 bytes, 9 note-ons across 8 velocities, full-range pitch bend reassembling 0..16383, two channels, zero desync, driven from Windows. Gate 3 was approved 2026-09-03.

What remains is unexplained and worth keeping: the S3's native port going dark and staying dark across CPU resets until a genuine power cycle. There is no root cause, no code change, and none of the three diagnostic next-steps produced a discriminating result. The bad-cable conclusion was explicitly retracted on 2026-09-02, because the S3 draws power from either port, so swapping both cables is also a power cycle and never a one-variable test. The two-move physical discriminator was never run, and the bench has been in host mode since, so device mode has not been re-exercised.

Suggested trim: retitle around the die-and-stay-dead port fault, drop the M3 and Device MIDI IN framing and the Blocks line, and keep the 2026-09-02 formulation as the live description.