DFU Converter

Mooching about on the internet I found this hackaday article detailing some automation to convert s standard binary to Dfuse so it can be loaded directly to STM devices.

https://hackaday.io/project/4139/instructions

Anyone tried it?

No, I am on Linux, so I just use objdump to generate the .bin from the .hex file and use dfu-util like this:
https://github.com/libopencm3/libopencm3/wiki/USB-DFU

as i used linux, dfu-util works pretty well for me for both ‘normal’ DFU as well as DFUse (ST’s DFU), the benefit for ST’s DFU is that you can specify an address it is an extension to the original DFU 1.1 specs. i’d think it would be good if USB org updates the specs to include ST’s DFU in the standard specs
http://dfu-util.sourceforge.net/

a strange feeling is that DFU may simply become the defacto firmware upgrade method, at least for mcus
the prevalence of maple mini, blue pill, etc, is having a ‘quiet’ evolution, we are in the age of the generic usb device
the usb device whose use case is up to you to define and program

DFU is the USB recommended standard for Device Firmware Upgrade, so it is more than de facto

i’d prefer it if stm could start introducing usb devices with usb 2.0 high speed (or even 3.x high speed) built in
these days even cheap sd card readers are usb 2.0 (or usb 3.x) high speed

Having >480 MB/s speeds on MPU devices featuring only < 200 MHz CPU frequencies and memory < 1 Mbyte is generally not very useful, except in some specific streming applications, so not worth the extra silicon die real-estate, better used to cram more peripherals.

As DFU(Se)!is integrated into ROM on newer STM32 devices, this one comes for free for these MCUs, and costs 8 Kb of Flash on older devices, compared to 4 Kb for a driverless HID (Human-Interface Device) bootloader or 10 Kb for a larger driverless MSD (Mass-Storage Device) bootloader, but thse still need a userland utility to flash a firmware anyway.

I really enjoy the rom-based MSD bootloader with FAT support proposed in the NXP LPC13xx devices, which presents the user with a familiar drag and drop drive to read/write the firmware.

Much as I love linux (and use it daily), I can’t drag myself away from a Windows desktop – I’m 47 and still hooked on FPS Games

That is the problem: I am 52, but not game-addicted

However, dfu-util also exists on Windows:
https://sourceforge.net/projects/dfu-util/files/

[ag123 – Wed Dec 19, 2018 5:56 am] –
the prevalence of maple mini, blue pill, etc, is having a ‘quiet’ evolution, we are in the age of the generic usb device

Interesting point. I actually started in this industry by making the “user land” software to interact with custom HID devices (powered by good old LUFA on ATMegas), so that the customers no longer needed to mess with drivers to operate the company’s devices. At the time (late 2000’s), it was significant competitive edge when contrasted with the competition.
It’s almost like making things simple and reliable for the end user as value

Dreaming of an F4 bootloader….

F4 has the DFUSe bootloader in ROM.

[BennehBoy – Wed Dec 19, 2018 10:05 am] –
Dreaming of an F4 bootloader….

The HID bootloader has AFIK been ported to the F4

[Squonk42 – Wed Dec 19, 2018 10:22 am] –
F4 has the DFUSe bootloader in ROM.

Yup, but this requires BOOT 0 to be set high. I want my cake and eat it so that I can just program via USB without setting any jumpers.

[RogerClark – Wed Dec 19, 2018 11:37 am] –
The HID bootloader has AFIK been ported to the F4

I’ll take a look, I’ve been away a little while so will need to read up on it.

[BennehBoy – Wed Dec 19, 2018 11:51 am] –
Yup, but this requires BOOT 0 to be set high.

Not BOOT0 but a predetermined (normally BOOT1) pin is set to keep in HID bootloader mode.
And only if you don’t use USB serial.
Otherwise, using USB serial, you don’t have to deal with setting pins, it works just like the F103 stm32duino bootloader.

i think on F4 you could set some (soft BOOT0) registers so that at reset it boots into DFU mode
the slight trouble with stm dfu is that it may not do a usb reset. i.e. the board reboots but to the host pc it would seem that nothing has changed.
that may mean having to ‘unplug and plug’ the usb cable, i’d think that’s where it is somewhat more inconvenient

[stevestrong – Wed Dec 19, 2018 12:18 pm] –

[BennehBoy – Wed Dec 19, 2018 11:51 am] –
Yup, but this requires BOOT 0 to be set high.

Not BOOT0 but a predetermined (normally BOOT1) pin is set to keep in HID bootloader mode.
And only if you don’t use USB serial.
Otherwise, using USB serial, you don’t have to deal with setting pins, it works just like the F103 stm32duino bootloader.

Hmm, deffo need BOOT0 high on mine to get into DFuse mode (BLACK407VET6) – incorrect labelling?

But, I guess you’re referring to this in relation to your fork of Roger’s core, I’m more interested in this for STM’s core – there’s a CDC PR awaiting release 1.5 which will add USBSerial…. Does that mean that out of the box the ROM built in Dfuse will work without BOOT0 (or 1 ) High? Or will it still be necessary to use a bootloader such as the HID one. I Guess @fpistm will be all over this.

EDIT wait, you’re talking about HID, I’m referring to DFuse (as per squonks post).

To enter DFU mode on the STM32F4 by software:
https://stackoverflow.com/questions/282 … stm32-f072

[Squonk42 – Wed Dec 19, 2018 12:48 pm] –
To enter DFU mode on the STM32F4 by software:
https://stackoverflow.com/questions/282 … stm32-f072

OK, so with CDC mode in the core this should be out of the box without a bootloader…. he says

FYI, hese is a blog post (in Russian, with a rough automatic translation available) on the STM32 Mass Storage Deviçe bootloader:
http://www.avislab.com/blog/stm32-bootloader_ru/

I did not’try it though, so I cannot tell what it is worth. I lost interest when I saw the required Flash size (11 Kb) and when I realized that within this size, the FAT FS was not included.

one ‘simple’ way is to port the stm32duino bootloader to f4, it’d take some effort though, but for now i’m quite happy setting the boot pins

i’m not really a fan of ‘mass storage’ boot loaders, usb mass storage presents a ‘block device’ to the host
and to fake all that folders and files etc, one’d need to code around and ‘simulate’ a fat file system, that may be moire work than necessary (on the mcu end) and the complexity could introduce bugs and may take some time to work out

but like roger mentioned the hid bootloader may well be a better option. based on what i read on the web, you would still need an app to download firmware
https://github.com/bootsector/stm32-hid-bootloader
but the difference is you may not need any drivers on windows that deal with the hardware unlike libusb which uses generic usb

Not interested in mass storage, but I suppose to flip the device into Dfu mode _will require_ a boot loader, the CDC inclusion will simply add USB serial to already running sketches.

I’ve had success with USB Serial using the STM github core (1.5.0) and PR #388 (CDC). So mucking about has been fruitful in that regard at least.

I think porting Roger’s bootloader is probably beyond me, but I might have a dabble.

i think much of that complexity has partly to do with the usb protocol itself

when a usb device is first plugged in the host does enumeration and make Get Descriptor requests
https://www.beyondlogic.org/usbnutshell/usb5.shtml

the descriptor data structure (most important being device class i think) we return to the host would make the host assume that we are that device class we claim to be CDC, DFU etc.
among the complications are that libmaple design first declare itself asVID:PID 1eaf:0003 device class DFU the bootloader does this, subsequently the board need to do a *usb reset* (done by the sketch)
so called single ended zero
http://www.usbmadesimple.co.uk/ums_3.htm
so that the host would enumerate again
and this time when we get a Get Descriptor request, we say we are VID:PID 1eaf:0004 and device class CDC (usb-serial)

for some reason it seem some of the boards e.g. stm32f407 black maybe blue pills, if the usb pheriperal is reset stm32 do not issue a ‘usb reset’ (single ended zero) to the host. we’d need to find a way to set both the D+ / D- low perhaps using digitalWrite to tell the host to enumerate again
there after we can tell the host we are VID:PID 1eaf:0004 and device class CDC (usb-serial)

usb is *hard to meddle in* i’m yet to touch beyond the superficial surface theories myself

to mess with usb i’d guess one would need some kind of usb protocol sniffer etc. i see many of those usb reverse engineering done that way.
i’ve been struggling to setup something to do that u’d need some s/w stack etc to meddle in it. some people use a RPi (or some such board) as a usb sniffer which i think is easier and more effective. s/w sniffers normally couldn’t capture the get descriptor event
https://www.raspberrypi.org/forums/view … p?t=167473
might be easier with the beagleboard
http://beagleboard.net/project/usbsniffer/
(edit: linux has usbmon built-in to the kernel
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
https://wiki.wireshark.org/CaptureSetup/USB
while in windows some utilities s/w is needed, i think s/w means is adequate to get into messing with usb dev
but i still find reading those usb specs ‘cryptic’,
https://www.usb.org/documents
e.g. while reading usb mass storage specs, little is actually mentioned that for the common usb mass storage protocol it is actually scsi over usb
and one would need to concurrently review scsi commands specs to understand what is going on

i think it is quite possible to hack bp/mm + rpi into a usb protocol sniffer as well, could be rather ‘difficult’ to do that and is itself pretty much a project
https://www.plop.at/en/teensy.html

Effort to reward ratio is favoring the BOOT 0 pin

If you are interested in HID bootloader for F4 see my repo
https://github.com/Serasidis/STM32_HID_Bootloader

Well, I spent an hour trying to get the HID bootloader to work, simply does not enumerate post flash. Tried forcing BOOT1 high and still get nothing

PS this is on Black 407VET6. it works just fine on Bluepill.

So I installed gnu make and built the bootloader from source code, uploaded the bin using st-link and it works fine. No idea why it won’t work if I use the .hex versions in the repo.

i think if you use dfu-util, it only works with *bin* files, i think ‘hex’ files won’t work with dfu-util.
the solution is to change that obj-dump builder to make bin files rather than hex files

[ag123 – Thu Jan 03, 2019 5:24 pm] –
i think if you use dfu-util, it only works with *bin* files, i think ‘hex’ files won’t work with dfu-util.
the solution is to change that obj-dump builder to make bin files rather than hex files

I used st-link.