Follow-ups to PR #647: HWCDC comment + upload-path reboot prompt#652
Conversation
…loses #650) The boom UART pin comment hypothesized that a future framework upgrade could let UART0 silently re-claim GPIO 3 and recommended Serial.end() as the fix. PR #647's bench-bisected HWCDC use-after-free finding makes that advice dangerous: on this hardware Serial is HWCDC over USB-OTG, and HWCDC::end() deletes tx_lock without waiting for in-flight writers — wedge-on-boot territory with no recovery path. Replace with a pointer to the Helpers.cpp explanation and note the correct resolutions if the hypothetical re-claim ever fires (Serial0.end on the real UART0 handle, or GPIO-matrix detach). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ry (closes #651) PR #647 added the 416-boundary reboot prompt to HandleConfigSave (the dropdown-form path). HandleConfigUpload (XML upload via /aoaconfigupload) bypassed it: LoadConfigFromString mutates g_Config.iLogRate directly and never runs through the per-field rebootRequired setters, so a pilot uploading a 416-Hz config to a 208-Hz running box would get a silent rate transition on the next power cycle. HandleConfigUpload now snapshots iLogRate's 416-ness before LoadConfigFromString and sets the new bUploadCrossedBoundary416 flag on a true crossing. HandleFinalUpload reads the flag and, if set, serves the same "Reboot Now" prompt that HandleConfigSave uses for the dropdown path. Banner wording mirrors HandleConfigSave for consistency. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Firmware ArtifactsMain firmware (Gen3 box)
Each External display firmware
Each The huVVer-AVI binary is built but not yet validated on real hardware — see the bring-up checklist for what to verify on first flash. X-Plane plugin
Drop the Built from
|
1 participant
Two post-merge follow-ups to PR #647
Both surfaced in the post-merge bulldog review. Each is small and independently revertable.
Fix 1: HardwareMap.h boom-UART comment no longer recommends `Serial.end()` (closes #650)
The existing boom-UART pin comment hypothesized that UART0 could re-claim GPIO 3 after a framework upgrade, and recommended `Serial.end()` as the fix. After PR #647's bench-bisected HWCDC use-after-free finding, that advice is actively dangerous — `HWCDC::end()` deletes `tx_lock` without waiting for in-flight writers, producing a wedge-on-boot with no recovery path.
Replaced the recommendation with a pointer to the explanation comment in `Helpers.cpp::_softRestart` and noted the correct resolutions if the hypothetical scenario ever fires (`Serial0.end` on the real UART0 handle, or explicit GPIO-matrix detach).
Fix 2: Config-upload path now surfaces the 416-boundary reboot prompt (closes #651)
PR #647's reboot prompt only fires from `HandleConfigSave` (dropdown-form path). `HandleConfigUpload` calls `LoadConfigFromString` → `ApplyPostParseSideEffects` directly and bypasses every per-field `rebootRequired` setter. Net effect: pilot uploads a 416-Hz config XML to a 208-Hz running box → no banner → next power cycle silently jumps to 416 Hz.
Added a `bUploadCrossedBoundary416` flag set in `HandleConfigUpload`'s `UPLOAD_FILE_END` branch on a true 416-boundary crossing. `HandleFinalUpload` reads the flag and serves the same "Reboot Now" prompt that `HandleConfigSave` uses for the dropdown path.
Verification
```
pio run -e esp32s3-v4p # SUCCESS
pio test -e native # 1168 passed, 1 skipped — no regressions
```
Bench testing
Not yet — both fixes are textual + a single page handler. Sam will bench the upload path on the next session; the comment fix is doc-only and doesn't need bench validation.
Related