theallelectricsmartgrid

October 3: WRLD one-way MIDI and a USB-reset firmware defect

Resolution update

Resolved in firmware; the user reports successful hardware behavior after deployment. The YTX task implemented the repair in commit 46e47e79e678adfe6e6cca06df871c9db8fd1803, followed by deployment documentation in 3cc49d6. These commits were landed and pushed to the repository’s joyo branch; the task verified that its fresh build matches the deployed image. The user approved deployment, reported “works nice land it” in the implementation task, and confirmed here that the MIDI problem is fixed. Exact reconnect-cycle counts and a post-fix iPad system capture were not supplied; do not describe this as an extended instrumented hardware trial.

The receive handler now resets/rearms its existing buffers and endpoint on configuration, restores DATA0, and protects reads against reset interrupts. A related MIDIUSB stale-read case was also corrected. Seventeen USB regression cases and three existing encoder checks passed; the firmware built using the modified repository core. MAIN-only deployment acknowledged all 870 blocks, and the controller answered a MIDI handshake and version request afterward. AUX firmware was unchanged. See the implementation record.

Deployed MAIN image SHA-256: 96579c17b96c7b5bc6e61fc162d8d642799a3d3256406a2ee631c73fee8ddb53. Local build/deployment artifacts remain at /private/tmp/wrld-usb-reset-build/, including final-output/ytx-main-controller.ino.app.bin and deployment-receipt.json. Bootloader acknowledgements and post-restart replies were verified; flash readback was not performed.

The MIDI failure has its own identified cause: powered USB reconnection exposed a WRLD firmware defect. Its appearance after Maya recovery was not evidence that the two devices shared an underlying fault. Maya audio remains the open investigation, with startup silence and periodic corruption retained as separate observations until their relationship is established.

The remaining sections record the investigation before the repair and deployment.

Finding and confidence

The user reports a reliable reproduction: start with working bidirectional MIDI, unplug/reconnect only the iPad-to-powered-hub cable, and WRLD → iPad continues working while iPad → WRLD feedback stops. They confirmed the controller was in that state during this investigation. Earlier WRLD-only power cycles restored feedback; restarting SmartGrid did not.

A concrete receive-endpoint reinitialization defect was found in the YTX firmware source and reproduced using that source in a local register model. The locally saved firmware ELF contains the same defective branch. It is a strong causal candidate at this stage; the original firmware actually flashed on WRLD was not identified byte-for-byte. The failed hardware state was preserved during the initial investigation. See the later resolution update above.

This finding concerns one-way WRLD MIDI. It does not establish a cause or fix for Maya’s periodic audio corruption or startup silence.

Fresh failed-state evidence

All times below are October 3, 2026, PDT (UTC−07:00). The saved iPad system archive covers 11:05:05–11:20:06, according to log stats; it includes one log-loss event, so counts describe retained messages. The app snapshot contains the session beginning at 11:00:05 and runs through 11:24:17.

Time Observation
11:13:18.695 / .719 USB2 and USB3 upstream hubs report hardware connection lost.
11:13:18.716 WRLD and Maya are removed because the upstream hub is terminating.
11:13:21 SmartGrid logs both WRLD MIDI ports disconnected.
11:13:24.832 / .833 USB2 and USB3 hubs enumerate again.
11:13:25.578 / .579 WRLD enumerates at 12 Mbps and configuration 1 is selected.
11:13:25.904 First retained WRLD endpoint 0x01 completion with 0xe0005000 (pipe stalled), zero bytes transferred.
11:13:27 SmartGrid successfully reopens both WRLD MIDI input and output ports.
11:20:06.996 Same OUT failure still present at the end of the capture.

There are 45,435 retained WRLD OUT pipe-stalled completions in this interval. SmartGrid’s send counters continue increasing, with native API errors=0 and the SysEx queue being submitted. App reconnect handling therefore did run; successful API submission did not mean USB delivery succeeded.

WRLD also has endpoint-zero transaction errors while enabling remote wake, followed by a compliance message. These are preserved in the context extract; they are not sufficient to explain the missing bulk OUT initialization.

The kernel’s pipe stalled label is not a wire capture proving that WRLD transmitted a literal USB STALL handshake. The chip documentation says a disabled OUT endpoint discards packets. The precise path from that condition to Apple’s reported pipe status remains unmeasured.

Firmware mechanism

Inspected checkout: /Users/joyo/ytx-controller, branch joyo, commit a2468bb5e3330648827afd97f7a7722b9a577259.

Relevant paths relative to that repository:

The causal sequence predicted by this code is:

  1. WRLD stays powered by the hub when the iPad cable is removed. The firmware’s receive-handler object remains in RAM.
  2. Reconnection includes a USB bus reset. The SAM D21 hardware clears nonzero endpoint configuration registers and endpoint interrupt enables/flags. This behavior is specified in Microchip DS40001882G, section 32.6.2.4, printed page 696.
  3. The host selects a configuration. Bulk IN initialization runs every time. Bulk OUT initialization, however, only constructs/configures a handler when its pointer is null. An existing pointer makes it skip the operation.
  4. The OUT endpoint therefore remains disabled and its receive interrupt remains off, while IN is enabled. WRLD can send but cannot accept new MIDI.
  5. A full controller reboot clears the pointer with the rest of startup RAM, allowing the initial constructor to configure OUT again.

The current Arduino SAMD USB core recreates an existing OUT handler during initialization. That implementation supports the need to reinitialize, but is not a patch to copy blindly into this older fork: the local handler owns two allocated buffers and has no destructor to free them. Repeated deletion/reallocation would also occur in USB interrupt handling. A focused repair should restore endpoint and buffer state safely, with reset/receive concurrency considered.

Local reproduction and provenance

The saved reproduce.py extracts the actual EPHandler, DoubleBufferedEPOutHandler, and USBDeviceClass::initEP source verbatim. It compiles them with a minimal register-admission model and sends a four-byte USB MIDI CC packet through the extracted handler. The modeled bus reset clears the documented endpoint configuration and interrupt state while preserving descriptor SRAM and firmware objects.

Observed result:

Condition OUT type OUT interrupt IN type Receive result
Cold boot / first configuration Bulk Enabled Bulk Packet received
USB reset / second configuration Disabled Disabled Bulk Packet rejected
Fresh MCU boot control Bulk Enabled Bulk Packet received

This reproduces a real initialization defect in the extracted code. It is a single-threaded model, not a USB wire simulator, live register inspection, or test of interrupt/main-loop races. It does not independently establish which firmware is flashed or prove the cause of the physical incident.

Disassembly of the existing /Users/joyo/ytx-controller/ytx-main-controller/build/ytx-main-controller.ino.app.elf confirms the same skip: initEP begins at 0x1d88c; the branch at 0x1d8d8 returns when the stored OUT handler is nonnull. The ELF’s identity relative to the current device is unverified.

The repository and installed Arduino core under /Users/joyo/Documents/Arduino/hardware/yaeltexv2/samd have identical SHA-256 hashes for both inspected files:

Initial implementation handoff and proposed physical test

The user authorized a new YTX task to fix the identified firmware defect: Fix WRLD MIDI receive after USB reconnect. It was started with the source findings, local reproduction, artifact paths, evidence limits, and instructions to implement/test in an isolated managed worktree. No firmware flashing, app restart, or hardware reset was authorized as part of the initial task. The user later approved deployment separately and reported success, as recorded above.

The decisive physical validation is a separately approved corrected-firmware trial: verify working bidirectional MIDI, keep the hub/WRLD powered, repeatedly disconnect/reconnect only the iPad-to-hub cable, and check actual feedback and controller input after each cycle. Confirm the built firmware uses the changed core rather than the unchanged global Arduino installation. Compare iPad OUT failures before and after. A pass would establish the fix for this reproduction; it would not resolve the separate Maya investigation.

If the physical symptom persists, read the controller’s endpoint configuration, interrupt and receive-completion state through an independent diagnostic path, or capture USB traffic. Do not make diagnostic replies depend exclusively on the broken host-to-controller bulk MIDI channel.

Local artifacts

Raw artifacts remain on the Mac and were not added to Git or uploaded:

The analysis directory contains current-usb.log, reconnect-context.log, archive-stats.txt, current-summary.json, source-provenance.json, existing-build-initEP.disassembly.txt, reproduce.py, generated repro.cpp, the local repro executable, and repro-result.txt. Its manifest.json records sizes and SHA-256 hashes for those ten files, verified after preservation. No capture remains running.

This site is open source. Improve this page.