Spark Logic

Trying to use F4x DFU bootloader

RogerClark Fri Nov 25, 2016 6:39 am

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]

Replies

ag123 Tue Nov 29, 2016 3:38 pm

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

RogerClark Tue Nov 29, 2016 7:08 pm

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.

ag123 Wed Nov 30, 2016 4:55 am

@roger

thanks much for the thoughts :D
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.

GrumpyOldPizza Wed Nov 30, 2016 12:42 pm

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.

Pito Wed Nov 30, 2016 1:28 pm

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

stevestrong Wed Nov 30, 2016 1:44 pm

Pito wrote:The “Maximite” syndrome :)

RogerClark Wed Nov 30, 2016 7:36 pm

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.

RogerClark Wed Nov 30, 2016 8:55 pm

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.

RogerClark Wed Nov 30, 2016 9:59 pm

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)

devan Thu Dec 01, 2016 2:13 am

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>

ag123 Thu Dec 01, 2016 4:12 am

@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

RogerClark Thu Dec 01, 2016 4:19 am

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 !

ag123 Thu Dec 01, 2016 5:01 am

@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 :lol:
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 :lol:
https://en.wikipedia.org/wiki/The_Cathe … the_Bazaar

RogerClark Thu Dec 01, 2016 5:15 am

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 :lol:
http://www.drdobbs.com/windows/no-end-t … /227300037

ag123 Thu Dec 01, 2016 5:36 am

the thing that’s most fun about the ‘DLL Hell’ is that even Microsoft has given up on solving it :lol:
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 :lol:

RogerClark Thu Dec 01, 2016 6:43 am

(LOL)

Sign in to reply