Hi everyone!
I'm not sure what to make of this, so I thought it's probably a good
idea to ask here first before filing a bug.
I'm flashing a GigaDevice GD32VF103TB (Pinecil) with dfu-util0.10. I
have compiled the latter from source, as there are supposedly some
issues with 0.9 and that's not available yet.
I have two machines, a Dell notebook and a Razer notebook. Both use the
same USB3/Thunderbolt dock.
With the Dell machine, I get this output every time I run dfu-util like
this:
sudo ./dfu-util-0.10/src/dfu-util -l
dfu-util 0.10
[cut the disclaimer]
Found DFU: [28e9:0189] ver=0100, devnum=17, cfg=1, intf=0, path="5-2.1",
alt=1, name="@Option Bytes /0x1FFFF800/01*016Be", serial="3TBJ"
Found DFU: [28e9:0189] ver=0100, devnum=17, cfg=1, intf=0, path="5-2.1",
alt=0, name="@Internal Flash /0x08000000/128*001Kg", serial="3TBJ"
However, when I connect it to my Razer, regardless of "directly" or via
the dock, the behaviour is like this:
FIRST run of dfu-util -l:
sudo ./dfu-util-0.10/src/dfu-util -l
dfu-util 0.10
[cut the disclaimer]
dfu-util: Cannot open DFU device 28e9:0189
From that, I just get nothing at all, just as if no dfu device was
connected at all.
Looking into lsusb, the device is present before running dfu-util and
gone after running dfu-util. Like I said, I have tested several
connections, so my suspicion now is, that - for whatever reason -
running dfu-util on my Razer makes the SoC "crash" so that it won't be
recognized by the computer any more.
However, I don't see a reason for this. I have checked the dfu-util
binaries, they are identical. Also libusb versions and even the kernels
are identical.
So, I'm not sure this is a bug in dfu-util and I have no expertise in
debugging this any further :(
What could I do from here?
Cheers
Steffen
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
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
Hi,
I consider the current git head to be a release candidate for the
upcoming 0.10 release of dfu-util, so I would be glad to see some
testing on various devices. I have tested on STM32F4 and will test
some custom IAP bootloaders. There are still known issues on STM32L4
and STMF0, but that has to wait for later releases.
Thanks,
Tormod
On Sat, Sep 5, 2020 at 1:30 AM Jakub Palider wrote:
> Hello,
>
> please, review the patch and, if okay, apply it.
> It was tested with some basic scenarios for the upload size and
> results are backward compatible and work for relevant parameters:
>
> Use expected upload size when reading from device
>
> In order to limit transfer on wires stop transmission when
> expected size is reached.
Just to update the list on this: After reviewing the DFU_UPLOAD
specifications and what our --expected-size option does (simply scale
the progress bar), we agreed to drop this patch.
Tormod
[sorry for breaking the thread, the original post disappeared from my mailbox]
Hello,
please, review the patch and, if okay, apply it.
It was tested with some basic scenarios for the upload size and
results are backward compatible and work for relevant parameters:
Use expected upload size when reading from device
In order to limit transfer on wires stop transmission when
expected size is reached.
Signed-off-by: Jakub Palider <jpalider(a)gmail.com>
---
src/dfu_load.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/dfu_load.c b/src/dfu_load.c
index 32c71b5..78db9ff 100644
--- a/src/dfu_load.c
+++ b/src/dfu_load.c
@@ -63,6 +63,15 @@ int dfuload_do_upload(struct dfu_if *dif, int xfer_size,
break;
}
+ /* If option --expected_size/-Z was issued then limit reading
+ size to the requested size and trim anything above that
+ limit (actual bus transfer may slightly exceed this value).
+ Here we also know rc < xfer_size which will stop transfer
+ down the execution path.
+ */
+ if (expected_size && (total_bytes + rc > expected_size))
+ rc = expected_size - total_bytes;
+
dfu_file_write_crc(fd, 0, buf, rc);
total_bytes += rc;
--
2.25.1
Regards,
Jakub
Welcome to the new dfu-util mailing list (archive)!. This list is for
discussing development and use of dfu-util. For normal bug reporting,
please file a ticket in the bug tracker.
Home page: https://dfu-util.sourceforge.net/
