dfu-util November 2020

dfu-util@lists.osmocom.org

2 participants
2 discussions

[ANNOUNCE] dfu-util 0.10 released
by Tormod Volden 21 Nov '20

21 Nov '20

dfu-util 0.10 has been released, and is available from http://dfu-util.sourceforge.net/ under "Releases". Thanks to everybody who contributed with patches, testing and bug reporting. >From the ChangeLog (see git history for full details): o New --wait option for devices to appear (Jörg Riechardt) o New --devnum option to filter devices (Harald Welte) o Support DFU_STATE_dfuMANIFEST_WAIT_RST (Jérôme Hamm) o Support large files (Tormod Volden) o Quirks for Jabra devices (Niels Skou Olsen) o Quirks for OpenPICC, SIMtrace (Harald Welte) o Quirks for GD32VF103 (Thomas Hebb) o Fix numeric argument parsing (Timo Poikola) o Improve alternate interface index matching (Aleks Chakin) o Improve libusb error messages (Alex Mastro) o Improve Stellaris firmware detection (Aleks Chakin) o Improve warnings and debug output (Tormod Volden) o Update manual page (Thomas Hebb) o Manual pages for dfu-suffix and dfu-prefix (Tormod Volden) o Usage text describes DfuSe modifiers (Uwe Bonnes) o dfuse: Erase all pages before programming (Geoffrey Hausheer) o dfuse: New "will-reset" option (Ievgenii Meshcheriakov) o dfuse: Allow 0 as start address (Xavier Domont) o dfuse: Workaround for Black Magic Probe issue (Tormod Volden) o dfuse: Workaround for STM32L4 page erase stalls (Tormod Volden) o dfuse-pack.py: Set (multiple) alternate interfaces (Tormod Volden) o dfuse-pack.py: S19 and ihex support (Thilo Cestonaro) o dfuse-pack.py: Intel HEX multi-segment index fix (Colin Parker) o dfuse-pack.py: Correct DFUImageSize (Hendry Kaak) o dfuse-pack.py: Python 3 compatibility (Michael Everitt) Known / possible issues: - Some STM32L4 chips may still show stalling issues (#40) - Building with MSVC hasn't been tested The binaries package (also in the release folder) includes 32-bit and 64-bit Windows binaries built on MinGW as well as macOS x86_64 binaries built on 10.13.6. It also includes an "lsusb" binary for these platforms, which might come handy for debugging. Latest git of libusb was used. Currently five issues/enhancements are milestoned for the next release: https://sourceforge.net/p/dfu-util/tickets/milestone/1.1/ Best regards, Tormod

1 0

Re: [Dfu-util] Forward of moderated message
by Tormod Volden 10 Nov '20

10 Nov '20

On Tue, Oct 27, 2020 at 8:13 PM Domenico wrote: > Is this the right repo? > > git://git.code.sf.net/p/dfu-util/dfu-util Hi Domenico, Yes, correct. It is also listed on the homepage http://dfu-util.sourceforge.net/ The latest commit hash is 5c323e45. > It seem that the -Z switch is ignored, no matter the value I specify > the data transferred from the device is 16384. > ID 0483:df11 > Run-time device DFU version 011a Thanks for testing! What is this device exactly? >From the above, your device seems to be a DfuSe device. In this case this is the expected behavior. I would recommend a DfuSe upload, specifying -s <address>:<length> The standard DFU upload offers no means for the host to request a certain length (or start), the device will simply transfer what should be the full firmware (or whatever payload that will be). If the host terminates the transaction prematurely, the result is undefined. In real cases the device will often hang or act up and must be reset. The -Z / --upload-size option name is a bit misleading, this only specifies an /expected/ payload size that will be used to scale the progress bar and nothing else. This was added because there is no way for dfu-util to know how long the payload will be. Some (all?) DfuSe bootloaders from ST seem to support a sort-of normal DFU upload, and will send back a payload without any hint of start address from the host. So I have preserved this functionality in dfu-util, more as a curiosity. However the bootloader doesn't terminate the transfer itself and my testing has shown that the bootloader will crash if the upload goes beyond the end of the flash memory. I therefore hardcoded a small size that I believe is safe for all devices. I should probably add a warning if this kind of upload is tried on a DfuSe device. Regards, Tormod

2 2

2025

2024

2023

2022

2021

2020

dfu-util November 2020