feat: preflight the Windows DFU driver before entering DFU mode - #95
Open
boringethan wants to merge 1 commit into
Open
feat: preflight the Windows DFU driver before entering DFU mode#95boringethan wants to merge 1 commit into
boringethan wants to merge 1 commit into
Conversation
…94) A field machine failed sensor updates for days with the SDK's "could not tell whether this device has the bootloader installed" halt; the cause was no WinUSB driver bound to the DFU device (0483:DF11), which only surfaced after the device was already stranded in DFU. Windows records the driver bound to every DFU device instance it has seen under HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_DF11, and the binding persists across re-enumerations — so the app now checks it at the two spots that are about to enter DFU (startConsoleFirmwareUpdate and _start_bootloader_thread) and refuses with an "install WinUSB via Zadig" message through the existing error signals instead. Blocks only on a positively unusable binding (driverless instance, or a service dfu-util can't drive such as ST's STTub30). A machine that has never enumerated a DFU device has no registry key and passes, so first flashes on fresh bench PCs are not affected; any single WinUSB/libusbK/ libusb0 binding clears the machine. The check never raises and any registry failure falls through to the old behavior. Verified live: this bench PC reports 7 recorded instances, all WinUSB, preflight passes. 76 app tests pass including 9 new ones. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #94
Why
A field machine failed sensor updates for days with the SDK's "could not tell whether this device has the bootloader installed" halt. Root cause: no WinUSB driver bound to the STM32 DFU device (USB 0483:DF11). The failure only surfaces after the device is already stranded in DFU, and nothing pointed at the driver.
What
Windows records the driver bound to every 0483:DF11 instance it has ever seen under
HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_DF11, and the binding persists across re-enumerations. Newdfu_driver.pyclassifies those bindings, and the two spots about to enter DFU —startConsoleFirmwareUpdate(all console/sensor firmware flashes, release + local) and_start_bootloader_thread(both bootloader installs) — now refuse up front with an actionable "install WinUSB via Zadig" message through the existing error signals when the machine positively cannot flash.Deliberate scoping:
Verification
tests/test_dfu_driver.pycovering all classification branches).WinUSB, preflight passes — matching the fact that this machine flashes successfully.🤖 Generated with Claude Code