Trying to use F4x DFU bootloader

Looking forward to more STM32F4 series devices becoming available, I am looking at trying to use the built in bootloader in the F4, which is USB DFU

I found some code here

https://my.st.com/public/STe2ecommuniti … ntviews=33

Reboot_Loader PROC
EXPORT Reboot_Loader
LDR R0, =0x40023844 ; RCC_APB2ENR
LDR R1, =0x00004000 ; ENABLE SYSCFG CLOCK
STR R1, [R0, #0] LDR R0, =0x40013800 ; SYSCFG_MEMRMP
LDR R1, =0x00000001 ; MAP ROM AT ZERO
STR R1, [R0, #0] LDR R0, =0x1FFF0000 ; ROM BASE
LDR SP,[R0, #0] ; SP @ +0
LDR R0,[R0, #4] ; PC @ +4
BX R0
ENDP ; [email protected]

STM32 parts use a version of DFU with some custom extensions that they refer to as DfuSe. The protocol layers some extra commands on top of the existing DFU commands to do extra things like specifying the start address to flash.

dfu-util has extra commands to handle DfuSe devices:
http://dfu-util.sourceforge.net/dfuse.html

Adding -s 0x08000000:leave should do the trick, i.e:
dfu-util -D C:\Users\rclark\AppData\Local\Temp\arduino_build_861808\Blink_PB0.ino.bin -a 0 -s 0x08000000:leave


@devan

Thanks, but it didnt work

I downloaded the W64 binary for dfu-util 0.9 from Sourceforge,
and tried

D:\Documents\Arduino\hardware\arduino_stm32\tools\win\dfu-util-0.9-win64>dfu-util -D C:\Users\rclark\AppData\Local\Temp\arduino_build_861808\Blink_PB0.ino.bin -s 0x08000000:leave -a 0

@roger
u got me sufficiently curious/excited to power up a STM32F407 board i’ve got for a while but have stashed it away and is collecting dust
https://www.olimex.com/Products/ARM/ST/ … e-hardware

olimex programmed the board so that if i boot into the normal flash the board emulates a mouse
Bus 003 Device 005: ID 0483:5710 STMicroelectronics Joystick in FS Mode

@ag123

My board has the USB connector on PA11 and PA12, just like a F103.

If I enable Boot0 I get the USB dfu device, so I used the libwdi installer we use or the maple dfu to force windows to install the driver.

I get the same sort of list if I try dfu-util -list

But I still cant upload.

I uploaded a sketch using STLink and if I call USBSerial.begin I can get a USB Device , but the PID and VID seem to show up as a “STM virtual com with FS”.

I need to check the core to see why it seems to be using STMs VID and PID, or whether I have really confused my PC as I have been testing some composite USB stuff for @Danieleff and my machine may be somewhat confused with PIDs and drivers at the moment.

I have not tried connecting the USB OTG but I have a STM discovery that I think has the OTG port connected to a USB socket.

But as these F407 boards are now under $10 USD, I think a lot more people will be buying them.

Btw. I posted to the other thread about f407 boards, that I expect we will end up doing our own F4 version of STMs core, as its been months since they released the F1 and L4 and we can probably get something working before they can

(not that this helps with the bootloading..)

@roger

apparently STM32F407 has 2 sets of USB OTG host controllers, on my board for reasons i do not know it uses (i.e. enumerates at boot) one port PA 9 , 11, 12 for DFU (this is apparently a full speed USB port) (it enumerates only this port for DFU) while the other, PA 13, 14, 15 (this is apparently a high speed USB port) (it enumerates only this port for app) when the app runs from flash

the schematics of the board i’ve is here
https://www.olimex.com/Products/ARM/ST/ … _B_sch.pdf
https://www.olimex.com/Products/ARM/ST/ … e-hardware

i’m observing a similar VID/PID for the ‘app’ that’s installed by olimex, it has an STM VID
Bus 003 Device 005: ID 0483:5710 STMicroelectronics Joystick in FS Mode

@ag123

I just looked in the code and for some reason the VID and PID are

/** @defgroup USBD_DESC_Private_Defines
* @{
*/
#define USBD_VID 0x0483

#define USBD_PID 0x5740

@roger
i’m running linux too, but then the other big wildcard is the PC & the usb cable itself

& on STM32 it’d seem STM may be keen on joining the mini-PC ‘revolution’, for what’s worth we may 1 day (soon) see a STM board ‘competing’ with the R-pi & beagleboards

Try to use -v (multiple times for increased verbosity) with dfu-util to get more information.

danieleff wrote:Try to use -v (multiple times for increased verbosity) with dfu-util to get more information.

in my case

in the case with an error
dfu-util -v -v -v -l

ibusb: debug [libusb_open] open 3.6
libusb: debug [usbi_add_pollfd] add fd 11 events 4
libusb: debug [add_to_flying_list] arm timerfd for timeout in 1000ms (first in line)
libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
libusb: debug [handle_events] poll() 4 fds with timeout in 60000ms
libusb: debug [handle_events] poll() returned 1
libusb: debug [reap_for_handle] urb type=2 status=0 transferred=8
libusb: debug [handle_control_completion] handling completion status 0
libusb: debug [disarm_timerfd] libusb: debug [usbi_handle_transfer_completion] transfer 0x14e23c0 has callback 0x7fd7d16865f0
libusb: debug [sync_transfer_cb] actual_length=8
dfu-util: Broken LANGID string descriptor
...
ibusb: debug [add_to_flying_list] arm timerfd for timeout in 1000ms (first in line)
libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
libusb: debug [handle_events] poll() 4 fds with timeout in 60000ms
libusb: debug [handle_events] poll() returned 1
libusb: debug [reap_for_handle] urb type=2 status=-71 transferred=0
libusb: debug [handle_control_completion] handling completion status -71
libusb: debug [handle_control_completion] low-level bus error occurred
libusb: debug [disarm_timerfd] libusb: debug [usbi_handle_transfer_completion] transfer 0x14e23c0 has callback 0x7fd7d16865f0
libusb: debug [sync_transfer_cb] actual_length=0
dfu-util: Failed to retrieve string descriptor 5
...


RogerClark wrote:danieleff wrote:Try to use -v (multiple times for increased verbosity) with dfu-util to get more information.

Sounds like STM may not have implemented their DFU to match the specification

I found this on Partice’s site

https://community.particle.io/t/tutoria … -2015/3518

I tried the version that the article linked to, but it was worse than the versions I’ve already tried.

But I”m sure what zadiag is going, and whether it installs a different driver than the libusb one that I’m using

@roger

i’m thinking that you may like to try out the DFU update app from STM since you are running Windows
http://www.st.com/en/development-tools/ … 32080.html

if STM’s s/w works while dfu-util doesn’t it possibly point to a software issue in dfu-util itself.

I doesn’t seem to recognise my DFU device.

I tried to find a ST Driver for their DFU device but couldn’t find one.

got a new *shielded* usb cable, better usb cables made a world of difference, no more errors

> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"
> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"
> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"
> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"
> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"
> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"
> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"
>
> ./dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes /0x1FFFC000/01*016 e", serial="3772346F3034"
Found DFU: [0483:df11] ver=2200, devnum=5, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="3772346F3034"

pulled the flash into a file as backup

./dfu-util -v -a 0 -Z 65535 -U stm32-app-backup.hex
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
Limiting default upload to 16384 bytes
Upload [=========================] 100% 16384 bytes
Upload done.


Roger, have you tried this?

Or here your have also a 64bit Win OS demo, although it is specified to work up to Vista/Win7 (including drivers), it may work for win10 as well, I haven’t tried yet.

stevestrong wrote:Roger, have you tried this?

Or here your have also a 64bit Win OS demo, although it is specified to work up to Vista (including drivers), it may work for win10 as well, I haven’t tried yet.

GrumpyOldPizza wrote:…pipe it throu their file manager type tool …

RogerClark wrote:danieleff wrote:Try to use -v (multiple times for increased verbosity) with dfu-util to get more information.

Umm.

Very strange.

I will try pulling the base of the PNP USB reset transistor, high, and also with it pulled low, to see if that helps.

i’m not sure if this may help, this link show another case of using dfu-util with STM32F407
it is probably a rather popular board STM32 F4 discovery board
the example is again linux though

https://github.com/micropython/micropyt … -Discovery

there are apparently more cases with a google search
https://www.google.com.sg/search?q=stm3 … covery+dfu

ag123 wrote:i’m not sure if this may help, this link show another case of using dfu-util with STM32F407
it is probably a rather popular board STM32 F4 discovery board
the example is again linux though

https://github.com/micropython/micropyt … -Discovery

there are apparently more cases with a google search
https://www.google.com.sg/search?q=stm3 … covery+dfu

@roger

thanks much for the thoughts
i’d take some time to test out dfu-util in windows. dfu-util works pretty well in linux with STM32F407, this includes STM’s DFUSe protocols, my earlier troubles is confirmed to be a faulty usb cable. but from the dfu-util -v -v -v logs that you have posted, apparently it does not seem to be a cable / hardware issue. The reason is that the install seemed to stop at a particular step, and the log message “The parameter is incorrect” could be the clue.

instead of specifying dfu-util -s 0x08000000:leave, you may like to try dfu-util -s 0x08000000 instead, without that :leave

windows environment is possibly very different from linux where the low level usb software interfaces go, i’m not too sure if for some reason dfu-util i.e. DFUSe didn’t work in windows due to the usb s/w interfaces. in addition, i’m not too sure if the command line parser could be having some troubles with the :leave in the address clause.

my thoughts with the STM32F4xx is that as they have a built in DFU boot loader or rather installer, we could possibly save some (a lot) of efforts from re-doing a DFU boot loader for F4, at least for a start. And in addition, the boot loader may as well consume (much?) less sram if we do not need the DFU codes.

olimex has apparently succeeded with an arduino implementation for STM32 F4x series

it is shown on the steps in the board manual chapter 7 page 22
https://www.olimex.com/Products/ARM/ST/ … 2-H407.pdf
they have uploaded the s/w in github
https://github.com/OLIMEX/Arduino_confi … master/STM

i’ve not tried this out and i’m not too sure if they are using dfu-util as well

LOL

Their Arduino loader

https://github.com/OLIMEX/Arduino_confi … upload.zip

Just a zipped up version of the files in my repo

Edit.

Looks like most of their files are just copies of the ones in my repo

For the STM32L4 core we use essentially this here:

dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D flash.bin

Some of the DFU implemenations for STM32 are known to be buggy (STM32L433 caught me out badly there). You might want to check AN2606 for issues and limitation of your specific device. Please also make sure that your platform runs properly with the builtin loader (the clock configuration might not be supported with your board).

The repro in terms of source that we use is https://github.com/arduino/dfu-utils-cross. There are a few fixes in there which may or may not be in the official source tree.

Sometimes the ERASE_PAGE timeout reported by the device is wrong … So you might want to hack that up to be 25ms minimum.

Looks like most of their files are just copies of the ones in my repo
The “Maximite” syndrome

Pito wrote:The “Maximite” syndrome

GrumpyOldPizza wrote:For the STM32L4 core we use essentially this here:

dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D flash.bin

Some of the DFU implemenations for STM32 are known to be buggy (STM32L433 caught me out badly there). You might want to check AN2606 for issues and limitation of your specific device. Please also make sure that your platform runs properly with the builtin loader (the clock configuration might not be supported with your board).

The repro in terms of source that we use is https://github.com/arduino/dfu-utils-cross. There are a few fixes in there which may or may not be in the official source tree.

Sometimes the ERASE_PAGE timeout reported by the device is wrong … So you might want to hack that up to be 25ms minimum.

GrumpyOldPizza wrote:For the STM32L4 core we use essentially this here:

dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D flash.bin

Some of the DFU implemenations for STM32 are known to be buggy (STM32L433 caught me out badly there). You might want to check AN2606 for issues and limitation of your specific device. Please also make sure that your platform runs properly with the builtin loader (the clock configuration might not be supported with your board).

The repro in terms of source that we use is https://github.com/arduino/dfu-utils-cross. There are a few fixes in there which may or may not be in the official source tree.

Sometimes the ERASE_PAGE timeout reported by the device is wrong … So you might want to hack that up to be 25ms minimum.

I installed the libusb driver I had configured for the F4 and reconnected the board and because I’d also loaded STM’s DFUSe demo the boar then appeared in the Windows device manager as “STM Device in DFU Mode”.

In this mode, STM’s demo gui will connect to the board and I was able to download the contents of the flash.

However STM’s DFUSe only supports its own file format and you have to convert .bin to .dfu though another gui

So I think using the internal USB DFU is going to end up being unworkable for most people ( I have enough questions with our existing bootloader, and thats far easier to use that this would be)

Here’s another data point:
I tested with dfu-util 0.7 and the latest dfu-util 0.9 on Windows 7 64-bit on the Seeed Arch Max board.

With WinUSB (or libusbK, since I had that installed for some reason), I had no issues:
C:\Users\Devan\Desktop\dfu-util-0.9-win64>dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D test.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08000000, size = 21544
Download [=========================] 100% 21544 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state

C:\Users\Devan\Desktop\dfu-util-0.9-win64>

@roger
just my 2 cents, as apparently the STM’s own DFUSe utility works and installed the sketch, to an extent it rules out a hardware problem.
and noting @devan’s observation ‘driver conflicts’ e.g. default STMicro driver conflicting with WinUSB, lib-usb, dfu-util stack could be a possible cause of the issue.

apparently in Windows, things are somewhat more complicated to manage as it seemed necessary to see that the software stacks:
1) WinUSB
e.g. from microsoft
https://msdn.microsoft.com/en-us/librar … s.85).aspx
2) libusb
https://sourceforge.net/p/libusb-win32/wiki/Home/
http://libusb.info/
http://libusb.org/
3) DFU-util
and
4) the registry settings to patch the VID/PID to the appropriate WinUSB / lib-usb / dfu-util stack
https://msdn.microsoft.com/en-us/librar … s.85).aspx
http://zadig.akeo.ie/
work in conjunction with each other and that they are uniformly 32/64 bits etc

in addition it is also necessary to be wary of driver conflicts such as a default STMicro driver patched to the same VID/PID etc

linux users is a little luckier as normally the kernel usb ‘driver’, lib-usb and thereafter dfu-util tend to be a default stack

Guys

I agree, its almost certainly a driver issue, as I have either the libusb via libwdi or ST’s driver, neither of which seem to work with any version of dfu-util which I’ve tried

I’ll need to install the libusbK driver using zadiag, but I was hoping to avoid needing to use zadiag, as I’m not sure if libusbK works with the F103 bootloader (I presume it does)

But I think the overall conclusion is that using the internal DFU in the F4 on windows is going to be problematic for a lot of people. Hence why it would be better if we had a USB CDCACM (Serial) based bootloader – or perhaps a HID or mass storage based bootloader, which windows recognises

My preference is for a Serial bootloader, as this would be even less confusing for people than the current DFU based bootloader for the F103 as a high percentage of the questions on the forum are ” I loaded the bootloader but I can’t see a serial device ”

And if we can use serial, we can use the built in tools in the IDE for uploading over serial USB (assuming we can increase the speed from 115200 to something much faster)

Most of the code to write a USB serial based bootloader already exists on the web, its just a question of putting it all together and getting it to work – which I know is easier said than done !

@roger
i’d think this is literally a manifestation of the ‘DLL Hell’, a task is probably to figure out which is the perfect combination of
WinUSB, lib-usb and the registry settings and all the lib-usb based apps e.g. dfu-util, usb-serial used by arduino / maple ide etc
http://www.drdobbs.com/windows/no-end-t … /227300037

A decade back it used to be Cathedral vs the Bazaar, today it has evolved into the Bazaar vs Bazaar
https://en.wikipedia.org/wiki/The_Cathe … the_Bazaar

ag123 wrote:@roger
i’d think this is literally a manifestation of the ‘DLL Hell’, a task is probably to figure out which is the perfect combination of
WinUSB, lib-usb and the registry settings and all the lib-usb based apps e.g. dfu-util, usb-serial used by arduino / maple ide etc
http://www.drdobbs.com/windows/no-end-t … /227300037

the thing that’s most fun about the ‘DLL Hell’ is that even Microsoft has given up on solving it
http://www.drdobbs.com/windows/no-end-t … 037?pgno=2

And shouldn’t there be more straight and distinct information to vendors and to system administrators? Experienced administrators who were confronted with 0xC0150002 in my presence had no idea how to proceed. Amusingly, Microsoft apparently published an article The End of DLL Hell a while ago, but all links to it (even those on http://www.microsoft.com) point to a page containing the text “This content has been removed”.

https://msdn.microsoft.com/en-us/library/ms811694.aspx

Content Removed
This content has been removed.

oops incorrect that ‘the end of dll hell’ article got moved elsewhere
https://web.archive.org/web/20010605023 … anger1.htm

(LOL)