Activity for dfu-util
-
Vinson created ticket #206
Failed uploading: uploading error: exit status 74
-
Horacio Saint Andre posted a comment on ticket #205
Around 47ms for a 120kB image and a 2kB block size (60 transactions). Indeed, I am not sure whether it would work for any combination of memory size/block size. As per AN3156, it seems to apply for all cortex-m series.
-
Tormod Volden posted a comment on ticket #205
Interesting, thanks! At a first view, this seems to make sense. It is limited to 65535-2 blocks though, but that can be dealt with if necessary. How much is the gain that you are seeing?
-
Use transaction block number for address offset
-
The warning that you put in the title is just a warning. It has nothing to do with "No DFU capable USB device available". Did you at all read https://sourceforge.net/p/dfu-util/tickets/new/ ?
-
Patricia Holden posted a comment on ticket #202
I have no idea, but it has not happened again since I last reported the anomaly.
-
Anonymous posted a comment on ticket #168
Quick update: same behavior with :fast, x5/6 times faster tho, nice job! I captured a trace using STM's flashing tool and I noticed that when I check the :leave equivalent button, the tool executes the command and keeps requesting the status until the device renumerates. Moreover between each get status, precisely 10 clear status are sent. I'll keep analyzing this and try to reproduce the behavior in dfuse_do_leave
-
Thank you Here at the dfu-util bug tracker we only deal with dfu-util itself, not the Arduino IDE. Arduino bundles their own modified version of dfu-util. This is the the problem that dfu-util sees (exit status 74 is just a code for this): |dfu-util: No DFU capable USB device available| So the Arduino IDE hasn't successfully made a DFU device available for dfu-util.
-
MKN posted a comment on ticket #204
Thank you On 8/11/24 3:28 PM, Tormod Volden wrote: summary: No DFU capable USB device available --> Arduino: No DFU capable USB device available status: open --> invalid Comment: Here at the dfu-util bug tracker we only deal with dfu-util itself, not the Arduino IDE. Arduino bundles their own modified version of dfu-util. This is the the problem that dfu-util sees (exit status 74 is just a code for this): |dfu-util: No DFU capable USB device available| So the Arduino IDE hasn't successfully made...
-
symbol lookup error after new install
-
So the /usr/local/lib/libusb-1.0.so.0 that you deleted showed up again after reboot? No, I have never run into this before. Maybe you have a boot script installing it, or a file syncing service that reinstates it.
-
Thanks so much, this solved the problem and I am now able to send the rootfs.ext4 file, but u-boot is rejecting it now (not dfu-util issue at this point). I think we can safely close this ticket.
-
It is happening again and I have not touched a thing. I rebooted my laptop, and tried to use dfu-util again. sudo dfu-util -l dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option ldd output: sudo ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffed54f7000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073306e600000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073306e200000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073306e9b2000) libpthread.so.0...
-
(LIBUSB_ERROR_ACCESS)
-
You should create a udev rules file for your device, see e.g. https://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/doc/60-dfuse.rules
-
Arduino: No DFU capable USB device available
-
Here at the dfu-util bug tracker we only deal with dfu-util itself, not the Arduino IDE. Arduino bundles their own modified version of dfu-util. This is the the problem that dfu-util sees (exit status 74 is just a code for this): dfu-util: No DFU capable USB device available So the Arduino IDE hasn't successfully made a DFU device available for dfu-util.
-
I have the same error with a new UNO R4 Minima. Arduino 2.3.2, Linux Fedora 40. So far, tried swapping cables, usb port, reboot, reset twice, verified the file 99-arduino-101.rules. The reset-twice operation crashes the linux host. And there are a lot of posts with this same error. Seems not quite ready for prime time, guys. Very frustrating.
-
Siddharth created ticket #204
No DFU capable USB device available
-
It is happening again and I have not touched a thing. I rebooted my laptop, and tried to use dfu-util again. sudo dfu-util -l dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option ldd output: sudo ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffed54f7000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073306e600000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073306e200000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073306e9b2000) libpthread.so.0...
-
Anonymous posted a comment on ticket #168
Same problem with 0.9. I haven't tested the :fast option, I'll do it on Monday.
-
Anonymous, can you share more details of your USB captures? And does version 0.9 work for you, like for the original poster?
-
Anonymous posted a comment on ticket #168
Hi, I'm facing a similar issue with the STM32F072 when plugging it directly to the host, and also when using a TUSB2077 hub. However, when using a RTS5411 or uPD720210 (two commercial hubs), everything works fine and the download is x5 faster (don't know why, but there is a lot of dfuDownloadBusy). Did you try to download your firmware adding and additional hub in between? Comparing usb captures from both cases, I see with direct plugging the renumeration doesn't happen as expected after the leave...
-
Manuel Rosa posted a comment on ticket #203
I think I found the problem. After run the command: sudo chmod -R 777 /dev/bus/usb/. It returned with: Found DFU: [0483:df11] ver=2200, devnum=11, cfg=1, intf=0, path="1-1.2", alt=1, name="@Option Bytes /0x1FFFF800/01016 e", serial="FFFFFFFEFFFF" Found DFU: [0483:df11] ver=2200, devnum=11, cfg=1, intf=0, path="1-1.2", alt=0, name="@Internal Flash /0x08000000/0320001Kg", serial="FFFFFFFEFFFF" MrGray@Beast:~ $ Hopping this will be Okay Now.
-
(LIBUSB_ERROR_ACCESS)
-
Thanks so much, this solved the problem and I am now able to send the rootfs.ext4 file, but u-boot is rejecting it now (not dfu-util issue at this point). I think we can safely close this ticket. On Tue, Aug 6, 2024 at 2:06 AM Tormod Volden tormod@users.sourceforge.net wrote: Exactly, your dfu-util binary is run-time linking a libusb in /usr/local/bin: libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) This is not the libusb that comes with the distro as part of libusb-1.0-0-dev,...
-
I followed the build manual on the dfu-util site. I already had libusb-1.0.0-dev installed. I did install dfu-util executable into /usr/local/bin. After running ldd: ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffee19ad000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073d5ad600000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073d5adcb8000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000073d5adcb3000)...
-
Exactly, your dfu-util binary is run-time linking a libusb in /usr/local/bin: libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) This is not the libusb that comes with the distro as part of libusb-1.0-0-dev, and which is referenced during building. Hence the mismatch when running dfu-util. Simply delete the (apparently very) old libusb that you have in /usr/local/lib.
-
I followed the build manual on the dfu-util site. I already had libusb-1.0.0-dev installed. I did install dfu-util executable into /usr/local/bin. After running ldd: ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffee19ad000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073d5ad600000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073d5adcb8000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000073d5adcb3000)...
-
Running dfu-util -l command multiple times, changing the device info.
-
It looks like a hardware issue on your device. You'd have to provide more information and debug logs, see what is demanded on https://sourceforge.net/p/dfu-util/tickets/new/
-
It could be that you are building against one version of libusb and then run-time linking against another version. To start with, make sure you are running the correct dfu-util binary: type dfu-util You said you built dfu-util 0.11 but did you install it, and where? /usr/local/bin ? Then run ldd on that file, e.g. ldd /usr/local/bin/dfu-util This will list which libusb .so file will be run-time linked. Typical candidates for confusion would be a custom-installed libusb in /usr/local/lib in addition...
-
dfu-util V0.11 error after new install
-
Cannot open DFU device
-
Please see the text on https://sourceforge.net/p/dfu-util/tickets/new/ (and Anonymous posters trying to hi-jack this report please see https://sourceforge.net/p/dfu-util/tickets/197/ )
-
fatal error occured: COM9
-
Please see the text on https://sourceforge.net/p/dfu-util/tickets/new/ (and Anonymous posters trying to hi-jack this report please see https://sourceforge.net/p/dfu-util/tickets/197/ )
-
Oliver Pfeifle created ticket #201
fatal error occured: COM9
-
Cannot ofen DFU device
-
As explained in the description: Note if dfu-util reports "No DFU capable USB device available" there is a 99% chance the error lies in your "microcontroller development" GUI / Arduino IDE or the device bootloader setup, and there is nothing dfu-util can do about it. In this case please consider reporting the bug in the appropriate channels and forums and not here.
-
Anonymous posted a comment on ticket #197
Sketch uses 285877 bytes (9%) of program storage space. Maximum is 3145728 bytes. Global variables use 30732 bytes (9%) of dynamic memory, leaving 296948 bytes for local variables. Maximum is 327680 bytes. dfu-util 0.11-arduino4 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/ No DFU capable USB device...
-
* Anonymous please post here *
-
Dennie created ticket #199
Running dfu-util -l command multiple times, changing the device info.
-
Warning: Invalid DFU suffix signature
-
The warning that you put in the title is just a warning. It has nothing to do with "No DFU capable USB device available". Did you at all read https://sourceforge.net/p/dfu-util/tickets/new/https://sourceforge.net/p/dfu-util/tickets/new/ ?
-
Fabio created ticket #198
Warning: Invalid DFU suffix signature
-
You must create a udev rules file so that the device 2341:035b gets tagged with "uaccess". Please see examples in https://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/doc/60-dfuse.rules
-
Anonymous posted a comment on ticket #197
Salut. c'est ma première fois j'utilise l'arduino portenta H7 et quand je téléverse un programme pour pour test j'ai ce message d'erreur. j'ai fait les configuration nécessaire niveau carte. mon problème semble être lié à mon port, j'utilise un système d'exploitation linux Unbutu
-
Anonymous posted a comment on ticket #197
dfu-util 0.10-dev 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/ dfu-util: Warning: Invalid DFU suffix signature dfu-util: A valid DFU suffix will be required in a future dfu-util release dfu-util: Cannot open DFU device 2341:035b found on devnum 7 (LIBUSB_ERROR_ACCESS) dfu-util: No DFU capable USB device...
-
* Anonymous please post here *
-
Anonymous please post here
-
Anonymous please post here
-
Anonymous please post here
-
Request for Assistance: Error Message 'No DFU Capable USB Device Available' When Uploading Firmware to ESP32
-
Unless the USB DFU device is available (and e.g. listed with lsusb) there is nothing dfu-util can do about it. dfu-util only does USB transfers (through libusb).
-
Maybe it is a permission issue. See https://sourceforge.net/p/dfu-util/tickets/186/
-
Afonso created ticket #196
Request for Assistance: Error Message 'No DFU Capable USB Device Available' When Uploading Firmware to ESP32
-
Anonymous posted a comment on ticket #186
Sketch uses 285877 bytes (9%) of program storage space. Maximum is 3145728 bytes. Global variables use 30732 bytes (9%) of dynamic memory, leaving 296948 bytes for local variables. Maximum is 327680 bytes. dfu-util 0.11-arduino4 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/ No DFU capable USB device...
-
Hey Tormod, I'll see if I can get that info for you.
-
Markus Pope posted a comment on ticket #145
Hey Tormod, I'll see if I can get that info for you. On Tue, Apr 16, 2024 at 2:56 PM Tormod Volden tormod@users.sourceforge.net wrote: status: open --> closed Comment: Closing since the fix has been pushed to git, but please report back what chip/bootloader version they were. [tickets:#145] https://sourceforge.net/p/dfu-util/tickets/145/ Updating firmware for STM32U5A9BJ required a small change to dfuse.c. Status: closed Milestone: 0.12 Created: Fri Oct 07, 2022 11:14 PM UTC by Markus Pope Last Updated:...
-
STM32F103 with software bootloader from STM32_USB-FS-Device_Lib_V4.0.0, 116KB binary: Tool Time[s] dfu-util git 9.3 dfu-util git :fast 6.3
-
STM32F103 with software bootloader from STM32_USB-FS-Device_Lib_V4.0.0, 8KB binary: Tool Time[s] dfu-util git 2.5 dfu-util git :fast 1.5
-
STM32F407 with a 1MB binary Tool Time[s] dfu-util git 55 dfu-util git :fast 28
-
STM32F103 with software bootloader from STM32_USB-FS-Device_Lib_V4.0.0, 8KB binary: Tool Time[s] dfu-util git 2.5s dfu-util git :fast 1.5s
-
libusb_control_transfer returned -9 (LIBUSB_ERROR_PIPE) on STM32F411CEU6
-
Slow download on STM32U5A
-
Updating firmware for STM32U5A9BJ required a small change to dfuse.c.
-
Closing since the fix has been pushed to git, but please report back what chip/bootloader version they were.
-
DfuSe: Testing of new :fast mode
-
There is now in git master a new ":fast" mode for DfuSe downloading, please see https://sourceforge.net/p/dfu-util/tickets/195/ I am posting this here because the tweaks made to support this fast mode may also help for some of the issues reported in this thread.
-
DfuSe: Testing of new :fast mode
-
Great to hear it works so well. Thanks for your testing! I have created a new issue for reporting results (and problems) with the new :fast option at https://sourceforge.net/p/dfu-util/tickets/195/ and I have copied over your above results there.
-
Copied from https://sourceforge.net/p/dfu-util/tickets/193/ STM32U5A5AJ with a 4MB binary [by Matthew] Tool Time[s] STM32CubeProgrammer v2.15.0 42 dfu-util 0.11 277 dfu-util git 166 dfu-util git with :fast 51
-
Copied from https://sourceforge.net/p/dfu-util/tickets/193/ Download times for 218 kB image to STM32L452RET (512 kB Flash) [by Henrik] Tool Time [s] STM32CubeProgrammer v2.15.0 7.262 s dfu-util 0.11 134 s dfu-util git 37s. dfu-util git with :fast 12.7 s
-
DfuSe: Testing of new :fast mode
-
Tormod Volden committed [be4961] on Code
dfuse: Allow direct transition to DNLOAD_IDLE on special command
-
Tormod Volden committed [570e0c] on Code
dfuse: Retry get_status if pipe error on download
-
Tormod Volden committed [814fa5] on Code
dfuse: New "fast" modifier for ignoring poll timeout
-
Matthew Albert posted a comment on ticket #193
Hello, excellent work! I just built the latest Git and applied the :fast patch and got the following results on my end: STM32U5A5AJ with a 4MB binary Tool Time[s] STM32CubeProgrammer v2.15.0 42 dfu-util 0.11 277 dfu-util-issue193 166 dfu-util-issue193fast 51 Features all seem to still work as expected even with the :fast modifier. Thank you so much for your support!
-
Henrik posted a comment on ticket #193
😁 Curiuosity also got the best of me, and I took a go at making a brute patch of dfu-util for testing, but never got it working correctly. I did however test -issue193fast this morning, and with '-s :fast' added to the command line download is much faster again and only takes 12,7 s, including erase! Thats more than a 10x improvement over dfu-utils 0.11. I have only performed limited testing, but it looks like everything is downloading correctly. This is definitely a well worth speedup, and I would...
-
Curiosity killed the cat... I have tried it out on some devices (STM32F407, STM32F103 with ST's old software bootloader) and it seems to work. These older bootloaders (correctly) report a zero poll timeout when in dfuDNLOAD-IDLE state, so there is "only" a 80-100% speed increase. More can be gained on these newer bootloaders where the poll timeout seems not correctly updated. Please apply the attached patch to latest git. There will now be a ":fast" modifer that can be added to the -s argument, and...
-
Tormod Volden committed [d0ecfe] on Code
dfuse: Ignore poll timeout for SET_ADDRESS special command
-
Tormod Volden committed [4faf70] on Code
dfuse: Only wait for poll timeout if in dfuDNBUSY state
-
I'd like to try it out and see if it works. I am quite a bit stretched for bandwidth right now, though. So I'm not sure when I would have time cook up a patch and to get the build enviromnent working.
-
I'd like to try it out and see if it works. I am quite a bit stretched for bandwidth right now, though. So I'm not sure when I would have time to get the build enviromnent working.
-
Do you refer to "The device uses the standard NAK mechanism for flow control, if necessary, while the content of its nonvolatile memories is updated." ? It is the only mention that I found. And I don't see that it exempts from the bwPollTimeout mechanism in section 6.1.2. So you'd suggest issuing the second (and following?) DFU_GETSTATUS immediately after the first, without waiting at all? I'd expect pipe errors to appear, although they can be handled. But should we just keep polling as fast as we...
-
I tested -issue913 and it is considerably faster at 37s. Still a far way from the ST downloader at 7 s. The USB DFU standard v.1.1 indicates that the MCU may use USB NAK as flow control if necessary. At least for a device such as the STM32L452, usb has interrupt support, and could easily support NAK flow control in the bootloader. And if the MCU supports responding USB NAK when it is busy, then it should be fine to issue DFU_GETSTATUS directly, without having to wait for bwPollTimeout ms first? Or...
-
I tested -issue913 and it is considerably faster at 37s. Still a far way from the ST downloader at 7 s. The USB DFU standard v.1.1 indicates that the MCU may use USB NAK as flow control if necessary. At least for a device such as the STM32L452, usb has interrupt support, and could easily support NAK flow control in the bootloader. And if the MCU supports responding USB NAK when it is busy, then it should be fine to issue DFU_GETSTATUS directly, without having to wait for bwPollTimeout ms first? Or...
-
Note also that in USB communication, the device must respond immediately to a host request, it is not possible to wait for some other slow operation to finish, or queue up requests.
-
Yes, that the commands only get executed on GET_STATUS is also part of the DFU standard. It is the GET_STATUS request that returns the bwPollTimeout value, and this is the time to wait before sending any new requests. The standard is made this way because simple microcontrollers may only do one thing at a time, and can be unable to reply to USB requests (such as GET_STATUS) while they are e.g. programming the flash.
-
There is now a snapshot "-issue193" (the 145 one didn't include everything here).
-
When looking at STs own DFU documentation, https://www.st.com/resource/en/application_note/an3156-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf no timeouts are actually mentioned. It does not seem too far-fetched to think that they do not have any timeouts for the polling at all. They write that the commands only actually get exectued when the following GET_STATUS command happens, and then I would guess that any following GET_STATUS just gets buffered inside the MCU, and gets...
-
Hang on, wait for the snapshot -issue193 to appear, because I missed something.
-
For benchmarking, please try also without any -v option, since the verbose logging might slow things down a bit.
-
The term "poll timeout" is confusing IMO. It is a reported duration that the host should wait before polling the device again. So every time the device reports a non-null poll timeout, dfu-util waits that long before continuing. I think it works faster with ST's tools because they are not too concerned about DFU compliance but know exactly what their bootloaders are doing. I have uploaded a new snapshot "-issue145" (it also includes a fix for issue 145) that you can try out, it contains the suggested...
-
Ok, then that explains why it was just as slow :) Apologies for my lack of insight, but what is it waiting for, and why does it time out? Adjusting the timeouts will make the wait shorter, but I guess that at some point you risk not waiting long enough between commands? Could it somehow be that the chip responds so quickly that the acknowledgement (or whatever is being polled for) gets completely missed? Is there any way to intercept the communications from the STM32CubeProgrammer to try and figure...
-
There hasn't been any changes in this regard, so the same performance was expected. However, there is more verbose debug information so that we can see what the bootloader is reporting. In your case we see there are definitely some things to look at. Erasing probably takes 2x the necessary time: Erasing page size 2048 at address 0x08000800, page starting at 0x08000800 Poll timeout 10 ms on command ERASE_PAGE (state=dfuDNBUSY) Poll timeout 10 ms on command ERASE_PAGE (state=dfuDNLOAD-IDLE) and programming...
-
Thanks. I tested with dfu-util_SNAPSHOT_20240415-win64.zip and it is still very slow. It took 137 s to download the same file again this time. Logs with -v -v attached
-
Henrik, please find a new Win64 snapshot here: https://dfu-util.sourceforge.net/snapshots/
-
I'd be happy to test with a different version, but it was not entirely clear to me how to build it for windows, and I do not have any linux machines available to build and test with.
1 >