qmk
Maple DFU fails part way through flash
Describe the Bug
When flashing using dfu-util on Windows 10 to STM32Duino Maple DFU the flash does not complete via QMK - it will get part way through the flash or then stop at various times - sometimes 0%, sometimes 33% or something in between - though will complete fine via the cli using the same command (I'm using binaries from http://dfu-util.sourceforge.net/releases/dfu-util-0.11-binaries.tar.xz (which seem to not be the ones in this project) )
System Information
- Operating system: Windows 10
- QMK Toolbox version: 0.22
Additional Context
Attempting to flash, please don't remove device
> dfu-util.exe -a 2 -d 1EAF:0003 -R -D "C:\Users\Eric\Documents\BlueSCSI-Updater\utils\BlueSCSI-v1.1-20220626-STM32F1-USB.bin"
> dfu-util 0.11
>
> Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
> Copyright 2010-2021 Tormod Volden and Stefan Schmidt
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
>
> Opening DFU capable USB device...
> Device ID 1eaf:0003
> Device DFU version 0110
> Claiming USB DFU Interface...
> Setting Alternate Interface #2 ...
> Determining device status...
> DFU state(2) = dfuIDLE, status(0) = No error condition is present
> DFU mode device DFU version 0110
> Device returned transfer size 1024
> Copying data from PC to DFU device
>
> Download [ ] 0% 0 bytes
> Download [ ] 2% 1024 bytes
> Download [= ] 4% 2048 bytes
> Download [== ] 8% 4096 bytes
> Download [=== ] 12% 6144 bytes
> Download [==== ] 16% 8192 bytes
> Download [===== ] 21% 10240 bytes
> Download [====== ] 25% 12288 bytes
> Download [======= ] 29% 14336 bytes failed!
> Warning: Invalid DFU suffix signature
> DFU state(10) = dfuERROR, status(14) = Something went wrong, but the device does not know what it was
> A valid DFU suffix will be required in a future dfu-util release
Flash complete
Attempting to flash, please don't remove device
> dfu-util.exe -a 2 -d 1EAF:0003 -R -D "C:\Users\Eric\Documents\BlueSCSI-Updater\utils\BlueSCSI-v1.1-20220626-STM32F1-USB.bin"
> dfu-util 0.11
>
> Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
> Copyright 2010-2021 Tormod Volden and Stefan Schmidt
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
>
> Opening DFU capable USB device...
> Device ID 1eaf:0003
> Device DFU version 0110
> Claiming USB DFU Interface...
> Setting Alternate Interface #2 ...
> Determining device status...
> DFU state(2) = dfuIDLE, status(0) = No error condition is present
> DFU mode device DFU version 0110
> Device returned transfer size 1024
> Copying data from PC to DFU device
>
> Download [ ] 0% 0 bytes
> Download [= ] 4% 2048 bytes
> Download [== ] 8% 4096 bytes
> Download [=== ] 12% 6144 bytes
> Download [==== ] 16% 8192 bytes
> Download [===== ] 21% 10240 bytes
> Download [===== ] 23% 11264 bytes
> Download [====== ] 25% 12288 bytes
> Download [======= ] 29% 14336 bytes
> Download [======== ] 33% 16384 bytes failed!
> Warning: Invalid DFU suffix signature
> DFU state(10) = dfuERROR, status(14) = Something went wrong, but the device does not know what it was
> A valid DFU suffix will be required in a future dfu-util release
> String descriptor 3 too short
Flash complete
The dfu-util bundled in the Windows Toolbox is taken from MSYS2: https://packages.msys2.org/package/mingw-w64-x86_64-dfu-util?repo=mingw64
Please also show the driver the device is using, and the stm32duino bootloader you flashed. For an STM32 Bluepill it's generally this one.
Zadig shows Maple 003 using libusb0 (v1.2.6.0) and yes I'm usining that exact generic_boot20_pc13.bin bin.
libusb0 is the wrong driver, it should be WinUSB. https://github.com/qmk/qmk_toolbox/blob/master/windows/QMK%20Toolbox/Usb/Bootloader/Stm32DuinoDevice.cs#L12
Well thats a bit odd then, why does the binaries from sourceforge work under the libusb0 driver? Is there a way to detect a non-preferred driver being used and report it to the user? I'll switch and give them both another try.
I'm not really sure, the dfu-util homepage claims it works with libusb 1.0 and "alternatively" 0.1, but the tar file only comes with the former. I know that the MSYS2 package is compiled with only libusb 1.0 support, so I think it's probably better to just stick with WinUSB.
Is there a way to detect a non-preferred driver being used and report it to the user?
This is what I added the PreferredDriver property for, but I haven't had the time to implement it yet.
Thanks for the tip - and I guess it "just worked" the first time with the SF binaries so I didnt look into it. Both the minigw and sourceforge bins work under WinUSB.
Sounds good on the PreferredDriver front! Great work on this app!