Activity for dfu-util
-
Mark Bell created ticket #232
No DFU capable USB device available Failed uploading: uploading error: exit status 74
-
Ognjen Galic posted a comment on ticket #231
...or, perhaps, to avoid hacks and stupid stuff just add a console switch to disable timeouts or raise them :^)
-
Hi, The F767 datasheet for this chip says 8 (in some crazy parallel mode) to 32 seconds. Yeah if we force such a timeout, it would slow down the tool a lot for other, real chips (STM32F0 chips mass-erase in 30ms). Maybe if we add up the flash size from the memory segments, and if they are "large" (1MB) and the controller lies, then set the large timeout? Thanks! Ognjen
-
Tormod Volden posted a comment on ticket #231
Then what if some other chip also reports 200 ms but doesn't need 35 seconds, maybe even correctly needs less than 200 ms? :) How many seconds does the datasheet say?
-
Hi, Should that be added to the 35 second quirk perhaps? Br, Ognjen
-
Poll timeout 200 ms on command MASS_ERASE (state=dfuDNBUSY) The chip tells dfu-util to wait 200 ms before asking about status again, but that is probably too short and the chip is still busy erasing and not able to communicate so our get_status request times out.
-
Hi, When you said it's verbose, you weren't kidding :^) The full output is attached. Many thanks! Ognjen
-
Can you please format the STM32H7 output? You can see in the STM32F407 output: "Setting timeout to 35 seconds". This is a quirk because we know some devices report wrong erase time. Maybe the F767 also reports wrong erase time. Please use -v -v to see more debug information. You can also use -v -v -v but that is so verbose you'd better attach the output as a file.
-
Here it is: STM32F767: ```C:\Users\ggurov\Downloads\epictuner-plugin-1.0-alpha-b18>dfu-util-static -v -d0483:df11 -a0 -s 0x08000000:mass-erase:force -D "C:\Users\ggurov\AppData\Local\Temp\epicEFI-dfu-update14162277243067594849\rusefi.snapshot.MEGA144F7\rusefi.bin" dfu-util 0.11-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/...
-
Windows git snapshot binaries can be found here: https://dfu-util.sourceforge.net/snapshots/ (2024-04-16 is practically latest git)
-
Hi, Is there any possibility that you could build us a git msvc x64 binary? I dont have the toolchain set up as im on Mac. Many thanks! Ognjen
-
If you are using latest git you can also try the new :fast dfuse modifier.
-
Please also use the latest version or latest git, because the diagnostics output has been improved.
-
Verbose logs might help, see https://sourceforge.net/p/dfu-util/tickets/new/
-
DFU download bricking STM32F767 and mass-erase is failing
-
Anonymous posted a comment on ticket #228
Sketch uses 1371041 bytes (43%) of program storage space. Maximum is 3145728 bytes. Global variables use 80364 bytes (24%) of dynamic memory, leaving 247316 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 posted a comment on ticket #228
I keep getting this error. How do I fix it
-
Haniya Haris created ticket #230
i am getting a error called No DFU capable USB device available Failed uploading: uploading error: exit status 74
-
Christian Schwaiger created ticket #229
ESP32 -WROOM-32 Ardoino Error Status 74
-
Nick Neupert posted a comment on ticket #227
Oh, a different error suddenly? File downloaded successfully Submitting leave request... dfu-util: Error during download get_status: -9 (LIBUSB_ERROR_PIPE)
-
Aries Beckett created ticket #228
No DFU capable USB device available Failed uploading: uploading error: exit status 74
-
The chip is a STM32G474RETx It uses this built-in bootloader API: https://www.st.com/resource/en/application_note/an3156-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf Bootloader version is 0xD5 (or v13.5) https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf
-
The chip is a STM32G474RETx It uses this built-in bootloader: https://www.st.com/resource/en/application_note/an3156-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf
-
The chip is a STM32G474RETx
-
No, I think the device is misbehaving. After receiving the "leave" request, it should answer the get_status request and actually only proceed to "leaving" afterwards. Which chip / bootloader is this?
-
The omission of the :leave option will also get rid of the error (but then the device will not be restarted). I am wondering if this is just a timing issue, that dfu-util is requesting the USB status before the device had time to restart.
-
The omission of the :leave option will also get rid of the error. I am wondering if this is just a timing issue, that dfu-util is requesting the USB status before the device had time to restart.
-
Tried it with git version and getting a different wording of the error: File downloaded successfully Submitting leave request... dfu-util: Error during download get_status: -4 (LIBUSB_ERROR_NO_DEVICE)
-
Yes, the firmware is downloaded successfully. I am worried about user confusion b/c this is a process the customers may have to do in the future. Will test latest git.
-
As you can see from "File downloaded successfully" the download is fine. It is the "leave" request afterwards that gives an error message.
-
Thanks! It is possible that this has been fixed in git after 0.11 was released. Can you please try latest git?
-
Show output with -v option added: sudo dfu-util -v -a 0 -i 0 -s 0x08000000:leave -D firmware.bin dfu-util 0.11 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/ libusb version 1.0.27 (11882) DFU suffix version 100 Match vendor ID from file: 0483 Match product ID from file: df11 Opening DFU capable USB device......
-
Show output with -l option sudo dfu-util -l -a 0 -i 0 -s 0x08000000:leave -D firmware.bin dfu-util 0.11 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/ Match vendor ID from file: 0483 Match product ID from file: df11 Opening DFU capable USB device... Device ID 0483:df11 Device DFU version 011a Claiming...
-
Computer environment: Linux Kubuntu 24.04 amd64 Exact version of dfu-util: from distro 0.11 Device: own device with stm32 Full command line used: sudo dfu-util -a 0 -i 0 -s 0x08000000:leave -D firmware.bin
-
I would need more info to tell. Please see what is written on https://sourceforge.net/p/dfu-util/tickets/new/
-
Error during download get_status
-
The warning is just a warning, and not really saying something goes wrong. What is the problem?
-
chu created ticket #226
Warning: Invalid DFU suffix signature
-
Xilinx (AMD) bootloader (FSBL) issues on Windows
-
Anonymous posted a comment on ticket #218
Seconding this solution. Thank you so much!
-
Rotoi created ticket #225
Error LIBUSB_ERROR_NOT_SUPPORTED with Arduino nano R4
-
MARCHAND created ticket #224
Arduino IDE error message
-
Bartel posted a comment on ticket #219
Same question here. Especially interested in the fixes to handle a reset device properly, e.g.: https://sourceforge.net/p/dfu-util/dfu-util/ci/83b4abcf8a2c168d8e4e5fc2261fc88ec22bb00c/ I am using this in an embedded Buildroot environment. And I had to manually add these patches to patch v0.11 in my build system, because else I got erroneous return codes from successful dfu-util upgrades.
-
It is not often that ELF files are used to provide firmware to end users as in this example. However it is often the primary build artifact so it would be convenient for development. It is interesting that StmDfuUsb supports ELF files because it is not mentioned on the home page https://yatrim.com/stmdfuusb I am not hugely in favour of adding all kind of file formats to dfu-util, because it adds complexity, maintenance burden and probably build dependencies. I would prefer it being added to the dfuse-pack.py...
-
Xavier Bestel posted a comment on ticket #223
I don't know what's inside. It's this device : https://skybean.eu/so-vario My question is more of a feature request : would it be possible to somehow parse ELF files do deduce the correct parameters for flashing ?
-
You mention StmDfuUsb but not anything about what device and bootloader it is. Please see https://sourceforge.net/p/dfu-util/tickets/new/ You can convert the ELF file to a binary using objcopy. If it is a standard DFU 1.1 device then that's all fine, but if it a DfuSe bootloader you must know where to load it, this information is in the ELF file but not in the binary file.
-
How to write elf file ?
-
Michal Zygmunt created ticket #222
dfu-util does not work on Windows ARM64 (Surface Pro etc)
-
Mark Ward posted a comment on ticket #221
I may have found the issue. In the script there are individual steps to programming the bootloader and application (the script being written by TI called usb_dfu_uniflash.py, in that scrip it checks the status of the target device using dfu-util -l between steps to check enumeration of the device to make sure it is ready for the next step. It looks like the -p <path> can change between steps and the script can't handle that. I am going to modify TI's script and see if I can make this more reliab...
-
I remember having seen, many years ago, an issue with a program running via Python's subprocess. I will try to recall or find back to it. You said that you added a lock that assures only one invocation of dfu-util is running at a time, but that didn't help. It therefore seems to me that the problem is not running dfu-util in parallel, but something else.
-
The failure looks to be hanging after the first block of data is transferred and before we enumerate the device again: Failing system [ 1.901426] [002f018d] libusb: debug [libusb_free_transfer] transfer 0x1cbf8ab0 DFU state(2) = dfuIDLE, status(0) = No error condition is present Done! [ 1.901440] [002f018d] libusb: debug [libusb_close] [ 1.901447] [002f018d] libusb: debug [usbi_remove_event_source] remove fd 7 [ 1.901492] [002f018d] libusb: debug [libusb_exit] [ 1.901567] [002f018e] libusb: debug...
-
This is the detailed log file from the hung dfu-util programming of AM243x - above was same failure without -vvv.
-
dfu-util hangs about 25% of the time when run in parallel via python subprocess
-
Thanks for your feedback. Yes, I have also been thinking about this and for long :) It is good to receive some feedback on the latest git, and that these changes have an impact. I usually don't hear anything on this side unless something is broken... I will look at retargeting those milestones and make a release soon.
-
Patrick Georgi created ticket #219
Create new release?
-
Arduino exit status 74 Failed uploading: uploading error: exit status 1
-
To clarify, this is a bug in the Arduino IDE (or its esp32 board package). You must report it there. Here on the dfu-util side there is nothing we can do. The Arduino people are bundling dfu-util with their setup, but we cannot fix their setup.
-
Anonymous posted a comment on ticket #218
Hi Christopher, Just letting you know, we've encountered the same situation (can be reproduced on win11 and win10). Turns out new MS Teams are probing USB devices (presumably searching for communication devices to use) which triggers a request for device language ID descriptor from each connected USB devices. Since Xilinx (AMD) bootloader (FSBL) does not know how to handle this request, it goes into some weird state which causes DFU to stop responding. Issue can be mitigated by closing MS Teams....
-
Christopher Willett created ticket #218
DFU commands don't work because Windows drivers invalid after updates
-
Kauri Halttunen posted a comment on ticket #217
I have the same problem. Using system information on macOS to see USB device details, this board used to work with USB device name "Nano ESP32" and manufacturer "Arduino". Now I get an error and it has the name "USB JTAG/serial debug unit" and manufacturer "Espressif". Below is the output while trying to upload using the Arduino IDE: Sketch uses 690741 bytes (21%) of program storage space. Maximum is 3145728 bytes. Global variables use 55048 bytes (16%) of dynamic memory, leaving 272632 bytes for...
-
Cannot open DFU device 2341:0366 found on devnum 34 (LIBUSB_ERROR_NOT_FOUND) This means the device shortly showed up, but then disappeared before dfu-util could connect.
-
Anonymous posted a comment on ticket #217
I have same issue: Warning: Invalid DFU suffix signature A valid DFU suffix will be required in a future dfu-util release Cannot open DFU device 2341:0366 found on devnum 34 (LIBUSB_ERROR_NOT_FOUND) No DFU capable USB device available Failed uploading: uploading error: exit status 74 This system is out of the box and not operating for sketch upload.
-
No DFU capable USB device available
-
No DFU capable USB device available Without more information there is not much we can do about it.
-
ali ugurlu created ticket #217
dfu
-
dfu-util 0.9 is pretty old. You should try to update your Arduino board package for your board/device. I don't think the dfu-util version is the real problem, but newer versions are more helpful for debugging. In any case, here it looks like the firmware file could not be found, so there is nothing dfu-util can do about it.
-
dfu-util doesn't access serial ports (nor virtual serial ports). LIBUSB_ERROR_ACCESS indicates a permission issue or driver conflict. Please see https://sourceforge.net/p/dfu-util/tickets/186/
-
Anonymous posted a comment on ticket #214
The same : Arduino UNO R4 detected with card information serial number and type (ttyACM0), compile, but when sending : 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/ dfu-util: Cannot open DFU device 2341:0069 found on devnum 7 (LIBUSB_ERROR_ACCESS) dfu-util: No DFU capable USB device...
-
Kari created ticket #216
Arduino exit status 74 Failed uploading: uploading error: exit status 1
-
Did you look inside the file?
-
Anonymous posted a comment on ticket #186
Bonjour Ou faut il le mettre ce fichier 60-dfuse.rules ?
-
You can use dfu-suffix to change or remove the VID:PID of the firmware file.
-
justin created ticket #215
Error: File ID does not match device
-
Please see https://sourceforge.net/p/dfu-util/tickets/186/
-
far jmp posted a comment on ticket #214
also: I can compile and upload to Arduino Nano, Uno, Mega w/o issues
-
Cannot open DFU device
-
Anonymous posted a comment on ticket #186
f you're having issues with DFU-Util: Just change the USB cable! Some cables only support charging but not data transfer. Hope this helps someone! 😊
-
Anonymous posted a comment on ticket #155
Greetings! Is there any chance to have this patch be applied in the near future? We do have some laptops here where a webcam always exposes it's dfu interface which dfu-util seems to prefer over our devices and it's kind of a pain to have to specify VID/PID for these devices.
-
Tormod Volden committed [f9a537] on Code
Move SourceForge links (and other links) to https
-
BTW, why are you using -t 0 ?
-
Warning: Invalid DFU suffix signature
-
Arduino ESP32 "No DFU capable USB device available"
-
Arduino Nano ESP32 "LIBUSB_ERROR_NOT_FOUND"
-
Arduino UNO R4 minima LIBUSB_ERROR_NOT_FOUND
-
Sri, I mistakenly thought it was you posting as anonymous above. Your original problem is the same as in https://sourceforge.net/p/dfu-util/tickets/207/ so I will close this ticket. You can reopen it if you have more information. The anonymous posters can post in https://sourceforge.net/p/dfu-util/tickets/197
-
candleLight flash can bus
1 >
