This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/dfu-util@lists.osmocom.org/.
Domenico Andreoli cavokz at gmail.comOn Tue, Oct 27, 2020 at 08:57:03PM +0100, Tormod Volden wrote: > 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, Hallo, > > Yes, correct. It is also listed on the homepage http://dfu-util.sourceforge.net/ > The latest commit hash is 5c323e45. Confirmed. You could also use (signed) git tags. > > > 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? This is an STM32F107VC (Olimex STM32-P107) but I also tested a GD32VF103 (Longan Nano), both are DfuSe devices and I had to use -D in combination with --dfuse-address. > > 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> Indeed it worked. > > 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. > I just tried to upload a new binary and see if it was being executed after reset. Anything else you might want me to check? Regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05