STM32F4 support and DFU

Dear friends,

Firstly I want to congratulate the stm32duino team for keeping this initiative alive for so long. I’ve personally visited these forums again and again before starting many different projects, just trying to discover a modern STM32 core finally fully supported by the Arduino IDE. I’m specially interested in the low-power familly of STM32 micros, which seem to not to be supported yet from the Arduino IDE. However, there is still the STM32F407 core, which seems very convenient for some other projects that I have in mind and the latest news seem to indicate that this core is now supported by the Arduino IDE.

Most of my boards need to be flashable fvia UART or USB. Discovery boards made by STM are including an on-board JTAG programmer but this is not an option in my case. Instead, I’d like to exploit the DFU feature available on the STM32 MCU by default. I read Roger Clark’s post about how the first firmware upgrade is really replacing DFU by a new serial botloader for the STM32F103 boards.

http://www.rogerclark.net/arduino-stm32 … l-and-dfu/

Is this still true for the STM32F4 platforms?

Let’s say I build my own STM32F407 board and select “STM32 Discovery F407” from Tools->Boards. I’m expecting JTAG to be the default upgrading mechanism for this board. Is there any other available board that I could take as a starting point instead of the Discovery one? Please take into account that I want to upgrade via native USB.

What features are still lacking for the STM32F4 boards when programmed from Arduino?

Thanks for your time and guidance.

The main reason of the bootloader is that F1xx doesn’t have DFU in silicon first stage loader, while the F4xx provide DFU even with empty flash.
You can still wish to have a bootloader in F4xx if you don’t want having to press the BOOT0 button and have automatic DFU.

There are now better Arduino cores for the F4.

Stm have their own core, and @danieleff has his own STM32_GENERIC core.

I would advise that you use one of them in preference to my core, for new developments

Thanks guys for your replies,

I’m installing against https://github.com/stm32duino/BoardMana … index.json. I thought this repo already included STM’s cores. Am I right?

Selecting from Tools->Boards->Discovery and then from Tools->Board Part Number->STM32F407G DISC1 offers two different uploading methods: ST-Link and Mass storage. Both seem to be supported only by the on-board JTAG chip so I’m still wondering how I could upload new code via DFU over native USB. Otherwise, I could easily call dfu-util from Arduino for my variant but I’m wondering if this is already supported by any other variant right now. Roger’s post about the limitation of DFU drivers when mixed with standard serial functionality makes me think that this is probably not the best approach.

Sorry guys for these basic doubts.

I think either method of uploading should work on that board as it has a dedicated STM32F103 chip to handle the uploads, independant of the main F4 MCU

OK but what if I’m using one of these simple boards?
http://www.ebay.com/itm/STM32F4-Discove … Swl1hZdWgE

They don’t have a separate JTAG or DFU emulator chip so I wanted to know whether Arduino could handle DFU through a native USB port on the STM32F407 MCU.

Thanks again,

If I set BOOT0 to 3.3V on my black F4 board, this device is recognized by Win10 64bit:

stm32f4 DFU device.jpg (38.81 KiB) Viewed 850 times

I don’t know if the F4 built in DFU works with the normal dfu-util

I think you need a DFUse utility to upload

Thank you very much for all the information.

See how the dfu-util works with F407:

http://www.stm32duino.com/viewtopic.php … =10#p32281

@pito

Are you sure you are using the dfu-util exe thats in my repo, because as far as I can tell, mine does not support the -s option, which you use in your commandline example in the other thread

@Roger, I am using a 64bit version, downloaded from somewhere.
From here

https://sourceforge.net/projects/dfu-util/

Can you email it to me ?

roger at rogerclark.net ?

https://sourceforge.net/projects/dfu-ut … t/download

README:
dfu-util 0.9

These binaries are for Microsoft Windows 64-bit

They were built using MinGW-64 from MSYS2 with gcc 5.3.0,
for build instructions please see:
http://dfu-util.sourceforge.net/build.html

Source code:
https://sourceforge.net/p/dfu-util/dfu-util/ci/v0.9/tree/

dfu-util.exe requires libusb-1.0.dll. The shipped libusb-1.0.dll
is built from libusb 1.0.20 and can be replaced with another
version if desired.

dfu-util-static.exe has the libusb 1.0.20 code embedded and runs
without any libusb-1.0.dll.

Notes:
1. To work around a bug in gcc/mingw, a small patch was applied, see
https://sourceforge.net/p/dfu-util/tickets/13/
2. The dfu-util-static.exe includes libusb that has been patched
to work around a silicon bug in STM32F42X devices:
https://github.com/axoloti/axoloti/blob/master/platform_osx/src/libusb.stdfu.patch

2016-02-11 Tormod Volden

Thanks

Umm

It still doesnt work for me

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 = dfuERROR, status = 10
dfuERROR, clearing status
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
error clear_status

UPDATE: I’ve tried with my Black F407ZE first time over USB DFU, basically the same board as yours. Win7 64bit.
1. I set Boot0 to 3.3V (was to GND)
2. unplug/plug usb (power off/on the board)
3. It recognized usb device and it installed STM32 BOOTLOADER (libusbK driver, 12/1/2014, v 3.0.7.0, dig signer USB\VID_0483&PID_DF11 (libwdi autogenerated) )
4. I ran dfu-util and uploaded a “d.bin” OK

Note: 3. – it was done automatically by Win7 64bit in my case, the info on the libusbK is from DevMan

AFAIK I installed the libusbK via latest zadig tool – http://zadig.akeo.ie/ [while your board is connected you open zadig tool, Options->List All Devices, and then select your Device – you will see a drop-down list with all your USB devices connected, then select the Driver for that Device and install]

I think all the issues with DFU are related to the PC-side driver..

@pito

Thanks

Using Zadig (which I already had on my machine) to install the libusb driver has fixed this for me.

I’ll need to work out what version of libusb is being installed by the libwdi installer, as it doesnt seem to be compatible with the internal DFU in the F4

The dfu-util README above indicates a fix due to a silicon bug in stm32F2..

i used something similar to this web
https://acassis.wordpress.com/2015/12/1 … stm32f407/
dfu-util -d 0483:df11 -a 0 -s 0x08000000 -D sketch.bin
i often get away with
dfu-util -a 0 -s 0x08000000 -D sketch.bin
if there is only a single dfu device connected

this is in linux though
the -s 0x08000000 is a necessary parameter for dfuse (stm’s dfu)

my guess is as you are able to do dfu-util -l, it would likely work with sketch install with the -s 0x08000000 parameter

On Windows … The reason that I could not DFU to the F4 were two fold.

1. the LibUSB driver that we use for the F1 DFU does not work correctly with the F4
2. The version of dfu-util we use with the F1 is not compatible with DFUSe needed for the F4

I think perhaps both the driver and the version of dfu-util which are included in the core, need to be updated.

However, I need to confirm that both of these work with the F1