27 Oct
2020
27 Oct
'20
8:57 p.m.
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 Nov
2 Nov
10:54 p.m.
New subject: Forward of moderated message
On Tue, Oct 27, 2020 at 08:57:03PM +0100, Tormod Volden wrote:
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.
On Tue, Oct 27, 2020 at 8:13 PM Domenico wrote:
Hallo,
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.
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?
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
10 Nov
10 Nov
12:20 a.m.
New subject: Forward of moderated message
On Mon, Nov 2, 2020 at 10:55 PM Domenico Andreoli wrote:
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.
Hi Domenico,
Thanks a lot for testing on your units. I don't have any particular
idea about what to test more. I think the DfuSe devices are rather
well tested by now.
I have added a warning if someone uses the "undocumented" upload
variant on DfuSe devices.
It seems possible that I can finish the release next weekend. I have
some changes queued up regarding error codes and their propagation but
I will rather land them after the release.
Regards,
Tormod
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.
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?
1800
days inactive
1813
days old
2 comments
2 participants
participants (2)
-
Domenico Andreoli -
Tormod Volden