- dfu-util - lists.osmocom.org

USB DFU found problem on STM32MP135F-DK in Microsoft Windows 10

by Piotr Lenarczyk

Dear Mr/Mrs, during work with ST Microelectronics STM32MP135F-DK board I have found, that after proper TF-A download there is a problem in dfu-util. Read USB DFU label is "UNKNOWN". This scenario is not reproducable under Linux dfu-util with the same set of software. I am not depended on this problem - it is informational only. Best Regards, Peter

1 year

1
0
0 0

Waiting for device with Arduino GIGA

by Matha Goram

Hello, This is not a bug and therefor I want to refrain from posting at the repository issues list. I'm running dfu-util to flash firmware to the GIGA board to start with MicroPython exercises. Here is the output: $ /usr/bin/dfu-util -w -a 0 -d 2341:0366 -D GIGAR1_MP_FW.dfu 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/ Waiting for device, exit with ctrl-C ^C The ports on the desktop are: from ttyACM0 to ttyACM5 from ttyUSB0 to ttyUSB3 The GIGA is connected through ttyACM4 libusb version 1.0.26 (11724) I used dfu-util successfully (thanks to Tormod's advice) by setting the configuration rules for the USB port. Naturally, the port assignments for the GIGA board change in my environment but the Arduino IDE 2.4 correctly detects the right port for the board. Do I have to set the port (in my environment) while using dfu-util to flash the firmware? There is a port parameter but I don't know the correct way to specify the port. Also, I couldn't use the -l parameter to gain insight on the connected devices. Also, some clarification on the -a parameter would help my understanding. Thanks. Regards.

1 year

1
0
0 0

DFU-Util Capabilities

by Stuart Blake Tener

DFU Util users/developers, I am new to using this utility and would like to understand if it applies to any my use cases. Use case 1 I recently came into some USB flash drives that I wish to change the vendor id and product id on (they have bogus vendor id and product id numbers making them un-writable). Use case 2 I would also like to be able to examine the firmware from a USB stick (several years ago I was scammed on a USB stick I purchased that had a bogus capacity and had to argue with PayPal to get my money back). So it is surely not an unreasonable thing to wish to check a USB stick's firmware for that or other security purposes (passive injection of code to impact BIOS or the OS). Can this utility perform any of the aforementioned enumerated activities when used in a Linux environment? If not, any idea what would do so? Mailing list question - can this email list be commanded to send daily or weekly digests or should I expect a multitude of emails coming from individuals replying to threads? Thanks in advance and do stay safe (avoid the thugs) and healthy. Stuart Very Respectfully, Stuart Blake Tener, BScCS, N3GWG (Extra), MROP Computer Scientist / FCC Licensed Radio Operator Las Vegas, NV / Philadelphia, PA (310) 358-0202 Mobile Phone (215) 338-6005 Google Voice

2 years

2
1
0 0

[dfu-util] UNDEFINED device listed with wrong PID:VID

by pierre.alaplantive.e＠sew-eurodrive.de

Hello, I am trying to load a bootloader on my LPC (NXP) microcontroller. I have installed LPCScrypt<https://www.nxp.com/design/microcontrollers-developer-resources/lpcscrypt-v…> and am using a script for it called boot_lpcscrypt.cmd where I call dfu-util -l in order to check if an NXP device in DFU mode is connected. I have it working on many computers but on multiple computers I get the following when I call dfu-util -l: C:\path\LPCScrypt>dfu-util.exe -l dfu-util 0.7 Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2012 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to dfu-util(a)lists.gnumonks.org<mailto:dfu-util@lists.gnumonks.org> Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU" Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="UNDEFINED" which means I cannot boot my image with the following command: C:\path\LPCScrypt>dfu-util.exe -d 0x1fc9:c -c 0 -i 0 -t 2048 -R -D "LPCScrypt_140.bin.hdr" More than one DFU capable USB device found, you might try `--list' and then disconnect all but one device I then did a dfu-util -l -vvv for verbose output which gave me the following log: C:\path\LPCScrypt>dfu-util -l -vvv dfu-util 0.7 Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2012 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to dfu-util(a)lists.gnumonks.org<mailto:dfu-util@lists.gnumonks.org> libusbx: debug [libusb_get_device_list] libusbx: debug [windows_get_device_list] allocating new device for session [320] libusbx: debug [get_api_type] driver(s): USBHUB3 libusbx: debug [get_api_type] matched driver name against HUB API API libusbx: debug [windows_get_device_list] allocating new device for session [2C5] libusbx: debug [get_api_type] driver(s): USBHUB3 libusbx: debug [get_api_type] matched driver name against HUB API API libusbx: debug [windows_get_device_list] allocating new device for session [10D] libusbx: debug [get_api_type] driver(s): USBHUB3 libusbx: debug [get_api_type] matched driver name against HUB API API libusbx: debug [windows_get_device_list] allocating new device for session [39B] libusbx: debug [get_api_type] driver(s): USBHUB3 libusbx: debug [get_api_type] matched driver name against HUB API API libusbx: debug [windows_get_device_list] allocating new device for session [328] libusbx: debug [get_api_type] driver(s): USBHUB3 libusbx: debug [get_api_type] matched driver name against HUB API API libusbx: debug [windows_get_device_list] allocating new device for session [FC] libusbx: debug [get_api_type] driver(s): USBHUB3 libusbx: debug [get_api_type] matched driver name against HUB API API libusbx: debug [windows_get_device_list] allocating new device for session [AD] libusbx: debug [windows_get_device_list] extra GUID: {A01674B4-C5F6-485C-AF94-3271701D57B4} libusbx: debug [windows_get_device_list] allocating new device for session [303] libusbx: debug [init_device] got bus number from ancestor #2 libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 27 bytes) libusbx: debug [init_device] (bus: 1, addr: 34, depth: 1, port: 4): '\\.\USB#VID_1FC9&PID_000C#ABCD' libusbx: debug [windows_get_device_list] allocating new device for session [13B] libusbx: debug [init_device] got bus number from ancestor #4 libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 34 bytes) libusbx: debug [init_device] (bus: 1, addr: 15, depth: 1, port: 2): '\\.\USB#VID_046D&PID_C312#8&4BDCEDF&0&2' libusbx: debug [windows_get_device_list] found existing device for session [39B] (1.0) libusbx: debug [init_device] got bus number from ancestor #3 libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 41 bytes) libusbx: debug [init_device] (bus: 1, addr: 13, depth: 1, port: 2): '\\.\USB#VID_05E3&PID_0607#7&2DC743E6&0&2' libusbx: debug [windows_get_device_list] found existing device for session [FC] (0.0) libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 41 bytes) libusbx: debug [init_device] (bus: 1, addr: 10, depth: 1, port: 7): '\\.\USB#VID_413C&PID_2134#5&18054507&0&7' libusbx: debug [windows_get_device_list] allocating new device for session [186] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 27 bytes) libusbx: debug [init_device] (bus: 1, addr: 34, depth: 1, port: 4): '\\.\USB#VID_0B0E&PID_245D&MI_03#6&2C280BB0&0&0003' libusbx: debug [windows_get_device_list] allocating new device for session [147] libusbx: debug [init_device] got bus number from ancestor #2 libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 34 bytes) libusbx: debug [init_device] (bus: 1, addr: 11, depth: 1, port: 1): '\\.\USB#VID_046D&PID_C050#6&2042894&0&1' libusbx: debug [windows_get_device_list] allocating new device for session [3BD] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 139 bytes) libusbx: debug [init_device] (bus: 1, addr: 4, depth: 1, port: 10): '\\.\USB#VID_0A5C&PID_5832#0123456789ABCD' libusbx: debug [windows_get_device_list] found existing device for session [AD] (1.0) libusbx: debug [init_device] (bus: 1, addr: 1, depth: 0, port: 0): '\\.\USB#ROOT_HUB30#4&1B12B7E5&0&0' libusbx: debug [windows_get_device_list] allocating new device for session [6C] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 705 bytes) libusbx: debug [init_device] (bus: 1, addr: 6, depth: 1, port: 11): '\\.\USB#VID_0C45&PID_6717&MI_00#6&C8B6A8F&0&0000' libusbx: debug [discovered_devs_append] need to increase capacity libusbx: debug [windows_get_device_list] allocating new device for session [116] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 177 bytes) libusbx: debug [init_device] (bus: 1, addr: 5, depth: 1, port: 6): '\\.\USB#VID_8087&PID_0A2B#5&18054507&0&6' libusbx: debug [windows_get_device_list] allocating new device for session [396] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 285 bytes) libusbx: debug [init_device] (bus: 1, addr: 16, depth: 2, port: 2): '\\.\USB#VID_0B0E&PID_2466#745C4B5ED2C4022600' libusbx: debug [windows_get_device_list] allocating new device for session [E2] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 245 bytes) libusbx: debug [init_device] (bus: 1, addr: 2, depth: 1, port: 1): '\\.\USB#VID_0B0E&PID_245D&MI_00#6&2C280BB0&0&0000' libusbx: debug [windows_get_device_list] found existing device for session [10D] (0.0) libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 31 bytes) libusbx: debug [init_device] (bus: 1, addr: 9, depth: 1, port: 22): '\\.\USB#VID_413C&PID_5534#5&18054507&0&22' libusbx: debug [windows_get_device_list] found existing device for session [2C5] (1.0) libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 25 bytes) libusbx: debug [init_device] (bus: 1, addr: 12, depth: 2, port: 1): '\\.\USB#VID_0409&PID_005A#6&225CC6B1&0&1' libusbx: debug [windows_get_device_list] allocating new device for session [325] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 245 bytes) libusbx: debug [init_device] (bus: 1, addr: 2, depth: 1, port: 1): '\\.\USB#VID_0B0E&PID_245D#745C4BB3D5CA015700' libusbx: debug [windows_get_device_list] found existing device for session [328] (1.0) libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 41 bytes) libusbx: debug [init_device] (bus: 1, addr: 8, depth: 1, port: 5): '\\.\USB#VID_413C&PID_2513#5&18054507&0&5' libusbx: debug [windows_get_device_list] allocating new device for session [DE] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 705 bytes) libusbx: debug [init_device] (bus: 1, addr: 6, depth: 1, port: 11): '\\.\USB#VID_0C45&PID_6717#5&18054507&0&11' libusbx: debug [discovered_devs_append] need to increase capacity libusbx: debug [windows_get_device_list] allocating new device for session [47] libusbx: debug [init_device] found 1 configurations (active conf: 1) libusbx: debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 39 bytes) libusbx: debug [init_device] (bus: 1, addr: 14, depth: 2, port: 1): '\\.\USB#VID_0B95&PID_7720#000001' libusbx: debug [get_api_type] driver(s): usbccgp libusbx: debug [get_api_type] matched driver name against Composite API API libusbx: debug [windows_get_device_list] found existing device for session [325] (1.2) libusbx: debug [get_api_type] driver(s): usbccgp libusbx: debug [get_api_type] matched driver name against Composite API API libusbx: debug [windows_get_device_list] found existing device for session [3BD] (1.4) libusbx: debug [get_api_type] driver(s): AX88772 libusbx: debug [windows_get_device_list] found existing device for session [47] (1.14) libusbx: debug [get_api_type] driver(s): usbccgp libusbx: debug [get_api_type] matched driver name against Composite API API libusbx: debug [windows_get_device_list] found existing device for session [DE] (1.6) libusbx: debug [get_api_type] driver(s): WinUSB libusbx: debug [get_api_type] matched driver name against WinUSB API libusbx: debug [windows_get_device_list] found existing device for session [303] (1.34) libusbx: debug [get_api_type] driver(s): BTHUSB libusbx: debug [get_api_type] lower filter driver(s): ibtusb libusbx: debug [windows_get_device_list] found existing device for session [116] (1.5) libusbx: debug [get_api_type] driver(s): usbccgp libusbx: debug [get_api_type] matched driver name against Composite API API libusbx: debug [windows_get_device_list] found existing device for session [396] (1.16) libusbx: debug [get_api_type] driver(s): HidUsb libusbx: debug [get_api_type] matched driver name against HID API API libusbx: debug [windows_get_device_list] found existing device for session [147] (1.11) libusbx: debug [get_api_type] driver(s): HidUsb libusbx: debug [get_api_type] matched driver name against HID API API libusbx: debug [windows_get_device_list] found existing device for session [13B] (1.15) libusbx: debug [windows_get_device_list] setting composite interface for [396]: libusbx: debug [set_composite_interface] interface[3] = \\.\HID#VID_0B0E&PID_2466&MI_03&COL03#8&88D4C0A&0&0002#{4D1E55B2-F16F-11CF-88CB-001111000030}<file://./HID%23VID_0B0E&PID_2466&MI_03&COL03%238&88D4C0A&0&0002%23%7b4D1E55B2-F16F-11CF-88CB-001111000030%7d> libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#INTC816&COL01#3&DC5EADA&0&0000' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#CONVERTEDDEVICE&COL02#5&2C48E802&0&0001' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#VID_044E&PID_1212&COL01&COL02#7&1A4DE3D5&0&0001' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#CONVERTEDDEVICE&COL03#5&2C48E802&0&0002' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#DLL07B0&COL02#5&42FDE31&0&0001' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#DLL07B0&COL01#5&42FDE31&0&0000' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#INTC816&COL02#3&DC5EADA&0&0001' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#CONVERTEDDEVICE&COL01#5&2C48E802&0&0000' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] setting HID interface for [147]: libusbx: debug [set_hid_interface] interface[0] = \\.\HID#VID_046D&PID_C050#7&26D304D6&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}<file://./HID%23VID_046D&PID_C050%237&26D304D6&0&0000%23%7b4D1E55B2-F16F-11CF-88CB-001111000030%7d> libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#VID_044E&PID_1212&COL01&COL01#7&1A4DE3D5&0&0000' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] setting composite interface for [396]: libusbx: debug [set_composite_interface] interface[3] already set - ignoring HID collection: \\.\HID#VID_0B0E&PID_2466&MI_03&COL01#8&88D4C0A&0&0000<file://./HID%23VID_0B0E&PID_2466&MI_03&COL01%238&88D4C0A&0&0000> libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#DLL07B0&COL03#5&42FDE31&0&0002' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] setting composite interface for [396]: libusbx: debug [set_composite_interface] interface[3] already set - ignoring HID collection: \\.\HID#VID_0B0E&PID_2466&MI_03&COL02#8&88D4C0A&0&0001<file://./HID%23VID_0B0E&PID_2466&MI_03&COL02%238&88D4C0A&0&0001> libusbx: debug [windows_get_device_list] unlisted ancestor for '\\.\HID#DLL07B0&COL04#5&42FDE31&0&0003' (non USB HID, newly connected, etc.) - ignoring libusbx: debug [windows_get_device_list] setting HID interface for [13B]: libusbx: debug [set_hid_interface] interface[0] = \\.\HID#VID_046D&PID_C312#9&34F37F38&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}#KBD<file://./HID%23VID_046D&PID_C312%239&34F37F38&0&0000%23%7b4D1E55B2-F16F-11CF-88CB-001111000030%7d%23KBD> libusbx: debug [get_api_type] driver(s): WinUSB libusbx: debug [get_api_type] matched driver name against WinUSB API libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [usbi_get_config_index_by_value] value 1 libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_open] open 1.34 libusbx: debug [libusb_claim_interface] interface 0 libusbx: debug [winusbx_claim_interface] claimed interface 0 libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [windows_assign_endpoints] no endpoints found for interface 0 libusbx: debug [auto_claim] auto-claimed interface 0 for control request libusbx: debug [winusbx_submit_control_transfer] will use interface 0 libusbx: debug [usbi_add_pollfd] add fd 2 events 1 libusbx: debug [libusb_get_next_timeout] next timeout in 0.997200s libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling libusbx: debug [handle_events] poll() 3 fds with timeout in 998ms libusbx: debug [handle_events] poll() returned 1 libusbx: debug [windows_handle_events] checking fd 0 with revents = 0000 libusbx: debug [windows_handle_events] checking fd 1 with revents = 0000 libusbx: debug [windows_handle_events] checking fd 2 with revents = 0001 libusbx: debug [usbi_remove_pollfd] remove fd 2 libusbx: debug [windows_transfer_callback] handling I/O completion with errcode 0, size 4 libusbx: debug [libusb_release_interface] interface 0 libusbx: debug [auto_release] auto-released interface 0 libusbx: debug [usbi_handle_transfer_completion] transfer 01026EB0 has callback 6B606A30 libusbx: debug [sync_transfer_cb] actual_length=4 libusbx: debug [libusb_claim_interface] interface 0 libusbx: debug [winusbx_claim_interface] claimed interface 0 libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [windows_assign_endpoints] no endpoints found for interface 0 libusbx: debug [auto_claim] auto-claimed interface 0 for control request libusbx: debug [winusbx_submit_control_transfer] will use interface 0 libusbx: debug [usbi_add_pollfd] add fd 2 events 1 libusbx: debug [libusb_get_next_timeout] next timeout in 0.997400s libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling libusbx: debug [handle_events] poll() 3 fds with timeout in 998ms libusbx: debug [handle_events] poll() returned 1 libusbx: debug [windows_handle_events] checking fd 0 with revents = 0000 libusbx: debug [windows_handle_events] checking fd 1 with revents = 0000 libusbx: debug [windows_handle_events] checking fd 2 with revents = 0001 libusbx: debug [usbi_remove_pollfd] remove fd 2 libusbx: debug [windows_transfer_callback] handling I/O completion with errcode 0, size 8 libusbx: debug [libusb_release_interface] interface 0 libusbx: debug [auto_release] auto-released interface 0 libusbx: debug [usbi_handle_transfer_completion] transfer 00EA3F98 has callback 6B606A30 libusbx: debug [sync_transfer_cb] actual_length=8 Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU" libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [usbi_get_config_index_by_value] value 1 libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_open] open 1.34 libusbx: debug [unsupported_open] unsupported API call for 'open' (unrecognized device driver) libusbx: debug [libusb_open] open 1.34 returns -12 Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="UNDEFINED" libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [parse_configuration] skipping descriptor 0xff libusbx: debug [parse_configuration] skipping descriptor 0xb libusbx: debug [parse_endpoint] skipping descriptor 25 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [parse_endpoint] skipping descriptor 30 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [parse_configuration] skipping descriptor 0xff libusbx: debug [parse_configuration] skipping descriptor 0xb libusbx: debug [parse_endpoint] skipping descriptor 25 libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_unref_device] destroy device 1.15 libusbx: debug [libusb_unref_device] destroy device 1.34 libusbx: debug [libusb_unref_device] destroy device 1.11 libusbx: debug [libusb_unref_device] destroy device 1.4 libusbx: debug [libusb_unref_device] destroy device 1.6 libusbx: debug [libusb_unref_device] destroy device 1.5 libusbx: debug [libusb_unref_device] destroy device 1.16 libusbx: debug [libusb_unref_device] destroy device 1.2 libusbx: debug [libusb_unref_device] destroy device 1.9 libusbx: debug [libusb_unref_device] destroy device 1.2 libusbx: debug [libusb_unref_device] destroy device 1.8 libusbx: debug [libusb_unref_device] destroy device 1.6 libusbx: debug [libusb_unref_device] destroy device 1.14 libusbx: debug [libusb_unref_device] destroy device 1.13 libusbx: debug [libusb_unref_device] destroy device 1.12 libusbx: debug [libusb_unref_device] destroy device 1.10 I find the following lines to be interessant: libusbx: debug [init_device] (bus: 1, addr: 34, depth: 1, port: 4): '\\.\USB#VID_1FC9&PID_000C#ABCD' libusbx: debug [init_device] (bus: 1, addr: 34, depth: 1, port: 4): '\\.\USB#VID_0B0E&PID_245D&MI_03#6&2C280BB0&0&0003' because USB#VID_1FC9&PID_000C#ABCD is my NXP microcontroller in DFU mode and I think USB#VID_0B0E&PID_245D&MI_03 is a Jabra Headset and for some reason they share the same configuration bus: 1, addr: 34, depth: 1, port: 4. Notice, that these are actually 2 different devices on 2 different USB ports. Then, from my understanding, dfu-util tries to open those devices with libusb_open, it works for USB#VID_1FC9&PID_000C#ABCD because it is in DFU mode: libusbx: debug [libusb_open] open 1.34 ... Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU" but not with USB#VID_0B0E&PID_245D&MI_03, which is a headset in normal mode. The output is: libusbx: debug [libusb_open] open 1.34 libusbx: debug [unsupported_open] unsupported API call for 'open' (unrecognized device driver) libusbx: debug [libusb_open] open 1.34 returns -12 I have 2 questions: 1. Shouldn't the output be corrected to give the correct VID:PID? to something like: Found Runtime: [0B0E:245D] devnum=0, cfg=1, intf=0, alt=0, name="UNDEFINED" 2. Is it correct, that USB#VID_1FC9&PID_000C#ABCD and USB#VID_0B0E&PID_245D&MI_03 share the same configuration bus: 1, addr: 34, depth: 1, port: 4 even though they are 2 different USB devices on 2 different USB ports? Is it a problem with dfu-util or with Windows? Can I fix this? Many thanks, Mit freundlichen Grüßen Pierre Alaplantive Embedded Software Entwickler tecmata GmbH Hagenauerstr. 57 D-65203 Wiesbaden Tel. +49 611 / 971 318 - 16 Fax. +49 611 / 971 318 - 99 mailto:pierre.alaplantive@tecmata.de http://www.tecmata.de<http://www.tecmata.de/> HRB 166446 München Geschäftsführer Manfred Engelhardt USt-IdNr.: DE253501120 Externer Dienstleister für: SEW-EURODRIVE GmbH & Co. KG Ernst-Blickle-Str. 42 D-76646 Bruchsal http://www.sew-eurodrive.de/ mailto:pierre.alaplantive.e@sew-eurodrive.de ________________________________ SEW-EURODRIVE GmbH & Co KG Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970 Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207 Geschäftsführender Gesellschafter: Jürgen Blickle Geschäftsführung: Jürgen Blickle (Vorsitzender), Udo Aull, Dr. Jörg Hermes, Dr. Hans Krattenmacher, Christian Mayer, Johann Soder, Dr. Jürgen Zanghellini

2 years, 3 months

1
0
0 0

[ANNOUNCE] dfu-util 0.11 released

by Tormod Volden

dfu-util 0.11 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): - Fix suffix check regression on Windows with Large File Support - Skip setting alternate interface when not needed - Only clamp transfer size on Linux - Quirk for GD32 leave request - Improve status and error messages and exit codes - dfuse: Process all alternate interfaces in a DfuSe file - dfuse-pack.py: Fix alternate settings if first is 0 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, and there are binaries with libusb statically linked, as well as dynamically linked. Best regards, Tormod

2 years, 7 months

1
0
0 0

Error on Ubuntu: Cannot set alt interface zero

by Jerry

3 years

2
1
0 0

Bug in dfu-util?

by Steffen Breitbach

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

3 years, 1 month

1
1
0 0

[ANNOUNCE] dfu-util 0.10 released

by Tormod Volden

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

3 years, 5 months

1
0
0 0

Re: [Dfu-util] Forward of moderated message

by Tormod Volden

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

3 years, 5 months

2
2
0 0

call for testing: dfu-util 0.10 RC

by Tormod Volden

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

3 years, 5 months

3
2
0 0

Re: [Dfu-util] Patch for activating --upload-size option

by Tormod Volden

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]

3 years, 6 months

1
0
0 0

Patch for activating --upload-size option

by Jakub Palider

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

3 years, 7 months

1
0
0 0

first post

by Tormod Volden

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/

3 years, 7 months

1
0
0 0

2024

2023

2022

2021

2020

dfu-util