The sketches need to be compiled for 0x08004000
I am attaching the bin file for the 407.
It should work with stack in normal RAM or CCMRAM.
I have tested the bootloader with the debugger, what I haven’t done yet is upload a sketch using it, because I do not know what tool can be used. The board gets detected as an STM DFU device.
I have never used the STM DFU uploads, took me a while to even find the driver I had to load to Windows, but the DFuse tool doesn’t take normal BIN files.
The bootloader currently takes under 13KB, but since the first page is 16KB, the whole page is reserved, and the sketch can is uploaded starting on the second page (0x08004000)
- F4Bootloader.zip
- (9.7 KiB) Downloaded 29 times
I downloaded Chris’s files but could not get them to build at all in True Studio. But I think this could be because I only have an old version installed
Did it build straight away for you, or did you need to change something in the True Studio project files.
Re; Uploading in DFUse format
Ah, that could be problematic.
i remember trying to use STMs DFUse tool but, like you say, it does not take binaries.
Did you try using Zadig to replace STs driver with the WinUSB driver, and then use the 64 bit dfu-until ( for Windows) which is in the tools folder of my repo?
I did manage to upload to the built in bootloader by doing those two steps.
Because the new version of dfu-util does not seem to work with linusb-win32 which the Maple DFU is compatible with.
I did try loading the WinUSB driver for the Maple VID PID but it does not seem to work
Ps you can use Wei-simple.exe to install WinUSB, you just use “type=0” instead of “type=1”
But make sure you manually uninstall the driver first before updating a device to WinUSB as I am not sure Wei-simple or Zadig remove existing drivers
I did also setup the tool chain etc on a Linux VM to build @devan’s bootloader, did a test build for the F1, and start to make the changes necessary for the F4, but the backup registers code was not compatible with the F4 and I think I got a load of other compile errors when I tried to build for the F4, so I had to park the code as I did not have time to figure out what was wrong.
I will probably just remove the backup registers code, as it’s not initially needed, but I think there were other things that prevented it compiling for the F4 
Then I made a few changes for the F407, since there is a few differences, but I probably spent 1/10 of the time doing those changes, vs what I spent trying to get it to compile in the normal Eclipse…
I’ll try those steps you mention to upload. If you have a chance to load the bin to a board and see if it gets detected with your drivers that will help too.
I’ve just dug out my Blue F4 board, so I’ll see if if you binary works .
Re: Eclipse
I had the same issues with True Studio.
I think perhaps it has missing some build targets.
I’ll download SystemWorkbench as well
Thanks
Roger
And I have the WinUSB driver already installed for that VID/PID
So I now need to modify the LibMaple F4 code to build with that offset
FYI
I’m currently modifying the libmaple F4 to handle having a different Vector offset passed from boards.txt
I’ve written all the code , but I am still testing it at the moment (i.e its not working !)
I did that, but forgot about the vector, good that you mentioned it, but had some other problems, so I’m about to try in a different computer.
I’ve got the vector table offset working with Libmaple F4
I added a bootloader menu to the generic , it currently still says “stm32duino bootloader” , but thats because I’ve not had time to change it 
Its a bit of a hack as for some reason I had to define the vector stuff for all boards even though there a added a ifndef into libmaple.h where it defined the USER_ADDR_ROM value, which is used in boards.cpp
The bootloader seems to hold for about 15 secs then jumps to the code and is flashing my LED
I now need to work on uploading via DFU
PS. Yes. I added a new linker file
See attached
Note. I only added the file for the Generic F4, as I’m using the “Blue F4” board at the moment for testing
PPS.
We need to add the code to toggle USB DP when the sketch runs, as it looks like the PC does not recognise the USB Serial device when the bootloader jumps to the application code.
Perhaps we can do that in the bootloader as my PC permanently shows the USB DFU device when my Blink sketch is running
static void setupNVIC() {
#ifdef VECT_TAB_ADDR
nvic_init(VECT_TAB_ADDR, 0);The files I posted did work for me, but only when I uploaded via STLink to 0x8004000
At the moment I can’t get dfu-util to work at all, it just keeps timing out and jumping to the application
I’m not sure if there is bug in the bootloader or if the problem is the command line, as I get a error message
Last page at 0x08009233 is not writeable
D:\Documents\Arduino\f4_bootloader_test>dfu-util -a 0 -s 0x08004000 -D f4_bootloader_test.ino.generic_f407v.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 = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08004000, size = 21044
Last page at 0x08009233 is not writeable
I tried using the internal bootloader using the same command (but setting the address to 0x8000000) and I was able to upload my Blink sketch
So there seems to definitely be some problem with Chris’s bootloader code.
I even tried setting the address to 8000000 in case you had hard coded the start address etc
e.g.
dfu-util -a 0 -s 0x08000000 -D f4_bootloader_test.ino.generic_f407v.bin
I’ll have to dig more in the bootloader to see what’s going on.
Btw I tried with libusbK driver that Zadig could install with the same result.
I think I have an idea of the problem. I get this when I use the -v option with dfuutil:
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: “Internal Flash “
Memory segment at 0x08000000 4 x 16384 = 65536 (r)
Memory segment at 0x08010000 1 x 65536 = 65536 (rew)
Memory segment at 0x08020000 3 x 131072 = 393216 (rew)
Downloading to address = 0x08004000, size = 24140
Last page at 0x08009e4b is not writeable
As you see all 4 of the initial 16KB pages are marked as (r) as opposed to the others being RW. Initially Chriss was reserving 4 pages for his bootloader, 64KB, but I changed that to 16KB. I must have left it unchanged in some place. I’ll get back to the code and check it up.
BTW, if I set the upload address to 0x08010000 in dfuutil, it uploads without any error.
OK
I did see that @pito was using the libusbK driver but WinUSB works fine for me using the built in bootloader, so I didnt try the libusbK version as it seemed to be irrelevant
OK.
I was going to suggest changing the offset vector to 0x8010000
but your code would not jump to that address, so even if it uploaded OK it would not run
Well, that is corrected now, all that’s left is the enumeration.
I have replaced the attachment in the first post with one that uploads correctly to the right address (0x8004000) and run the code from there.
It still has the long timeout, that can be changed later for the definitive version. Just need to correct the issue with not re-enumerating. I thought it would do it since the code was already there from Chriss, but perhaps needs a longer time.
I’ll download again and test
I’m getting the same error
Can you repost the zip file under a different name, perhaps there is a file cacheing problem
My mistake
I flashed the old version.
One thing however… Its not jumping to the sketch code when DFU is finished.
Is there any way we can get it to do that ?
I did try the -R option to reset, but that didn’t help
FYI.
I looked at resetting the board when the Magic sequence is received via Serial USB, but the F4 USB code is completely different to the code in the F1
The F1 has a “rxhook” which is configured so that the rxhook() function in usb_serial.c is called each time something arrives via CDCACM
But the F4 doesnt have this, and the CDCACM files look a lot different to the F1 versions.
So I didnt implement that functionality yet.
I did try to see if the reset code from the F1 would work with the F1, but again, the F4 underlying code does not have the nvic reset function etc.
I tried taking the assembler code from the F1 and parts of the F1 nvic reset code e.g. from scb.h etc, and put it in a sketch, but as far as I could tell, the F1 code would not work correctly on the F4.
However its a bit difficult to know if it had jumped to the bootloader or not, as the bootloader does not currently flash the LED.
I tried toggling USB DP using the normal code, before running the reset code, but the bootloader did not seem to respond to dfu-util.
Anyway, if its any use to you, here is my attempt at a sketch that would reset the MCU
(On my board. PB0 is the LED, so the code flashes the led 10 times, then calls reset_to_bootloader
reset_to_bootloader() drives PA12 (USB DP) low and then sets it back to floating, in the hope that when the board resets, the USB Host PC, notices that the STM DFU device has now appeared.
void setup() {
// put your setup code here, to run once:
pinMode(PB0,OUTPUT);
}
int c=0;
#include <libmaple/scb.h>
#define SCB_AIRCR_VECTKEYSTAT (0x5FA << 16)
#define SCB_AIRCR_VECTKEY (0x5FA << 16)
#define SCB_AIRCR_ENDIANNESS (1U << 15)
#define SCB_AIRCR_PRIGROUP (0x3 << 8)
#define SCB_AIRCR_SYSRESETREQ (1U << 2)
#define SCB_AIRCR_VECTCLRACTIVE (1U << 1)
#define SCB_AIRCR_VECTRESET (1U << 0)
void nvic_sys_reset() {
uint32 prigroup = SCB_BASE->AIRCR & SCB_AIRCR_PRIGROUP;
SCB_BASE->AIRCR = SCB_AIRCR_VECTKEY | SCB_AIRCR_SYSRESETREQ | prigroup;
asm volatile("dsb");
while (1)
;
}
#define RESET_DELAY 100000
static void wait_reset(void) {
delay_us(RESET_DELAY);
nvic_sys_reset();
}
#define STACK_TOP 0x20000800
#define EXC_RETURN 0xFFFFFFF9
#define DEFAULT_CPSR 0x61000000
void reset_to_bootloader()
{
//Reset the USB interface on generic boards - developed by Victor PV
pinMode(PA12,OUTPUT);
digitalWrite(PA12,LOW);
for(volatile unsigned int i=0;i<512;i++);// Only small delay seems to be needed, and USB pins will get configured in Serial.begin
pinMode(PA12,INPUT_FLOATING);
uintptr_t target = (uintptr_t)wait_reset | 0x1;
asm volatile("mov r0, %[stack_top] \n\t" // Reset stack
"mov sp, r0 \n\t"
"mov r0, #1 \n\t"
"mov r1, %[target_addr] \n\t"
"mov r2, %[cpsr] \n\t"
"push {r2} \n\t" // Fake xPSR
"push {r1} \n\t" // PC target addr
"push {r0} \n\t" // Fake LR
"push {r0} \n\t" // Fake R12
"push {r0} \n\t" // Fake R3
"push {r0} \n\t" // Fake R2
"push {r0} \n\t" // Fake R1
"push {r0} \n\t" // Fake R0
"mov lr, %[exc_return] \n\t"
"bx lr"
:
: [stack_top] "r" (STACK_TOP),
[target_addr] "r" (target),
[exc_return] "r" (EXC_RETURN),
[cpsr] "r" (DEFAULT_CPSR)
: "r0", "r1", "r2");
}
#define DELAY 250
void loop() {
// put your main code here, to run repeatedly:
for(int i=0;i<10;i++)
{
digitalWrite(PB0,HIGH);
delay(DELAY);
digitalWrite(PB0,LOW);
delay(DELAY);
}
reset_to_bootloader();
}
https://github.com/victorpv/F4Bootloader
This is the one that generates the BIN attached in the first post.
I compiled it using the latest Systemworkbench available from openstm32.org
The LED and button pins are defined in /inc/main.h
I probably wont have time to work on this any more today. If I get to do any progress I’ll updating it.
I will download System Workbench and see if I can build it
BTW.
The newer dfu-util which works with that bootloader does not seem to work correctly with the Maple bootloader.
It gets an error at the end.
So until I have time to fix the Maple bootloader we can’t simply switch to using the new dfu-util for both F4 and F1
I think I will also look at STM32GENERIC and STMs F4 cores, because LibMaple F4 is lacking in a lot of features and I don’t have time to update it
Which version of gcc are you using to compile the bootloader?
I’m getting errors on many of the files e.g. main.c gpio.c and some of the HAL files.
Apart from Arduino I’m running gcc 5.4, (as I need this for other MCU’s), but I’ll try configuring so that it uses the same compiler as the Arduino IDE, (which I think is V 4.8)
Edit.
I removed gcc 5.4 from my main PATH and it now compiles OK
I probably won’t have time to try this until tonight, but looking at the code it has
if(dfuActive(&USBD_Device) == 0) {
loops--;
}
FYI.
I recompiled it to flash the LED that is on my board (PB0), and eventually got it to work, but for a while it would not flash because PORTB had not been init’ed at all.
The code should probably init all the ports or have a #ifdef to make sure the button and led port are fully init’ed, not just the pins
I also shorted the delay, but I think more work needs to be done with that, as there is no need to wait after upload is finished.
I thought the DFU was supposed to reset the bootloader after its complete, and there seems to be some code which is using the Backup resister to determine if its in DFU or not, but I don’t know if thats the standard code from STM or something Chris added.
I have also been looking at integration with STM32Generic, as it already has the code for the F1 to reboot based on the magic sequence via USB Serial.
The problem however is the maple_loader.jar is not designed to work with the new version of dfu-util which needs the -s argument.
(Well I’m not sure if it is or not, as some of the comments metion commands for DFUse, but its not clear if thats the -s or something else
Either way the Maple bootloader and this F4 bootloader can’t both use the newer dfu-util that supports DFUse, so we’d need a separate bat file / script for the f4_loader which calls into the new dfu-util sub folder.
We also need a way to send the magic sequence, but I think that perhaps this can just be done in a bat file or a linux script etc
e.g.
ECHO "MAGIC" > \\.\com155:
About checking the Backup registers, it’s something Chriss added. That’s part of the Generic core. I believe Daniel use the same registers with the same values that we use on the F1 bootloader. That’s something you added and I didn’t look at it in detail, so I can’t confirm it they work exactly the same, but I believe they do since Daniel added it to his core to work with the F1 bootloader.
DFU has a reset command, but I think it doesn’t work. Agreed we need to get that part working better, either manage the reset command, or reboot on uploaded completed it that can be confirmed at runtime, thru some parameters of the DFU transfer like the size of the upload, or perhaps the DFU tool sends something else once the upload is supposedly completed.
One other thing I noticed, is that I believe the code doesn’t provide any protection for not overwriting the bootloader page. Instead it relies on the DFU tool to not try to write to that page. Since dfu-util seems to first check what pages are writable and only request that, at the moment it seems to work, but I think it’s a risk that a tool may request to write to the bootloader page and the bootloader would allow it. I need to read more the code to confirm that, but is my suspicion so far.
One more thing I have been thinking about.
We could integrate presenting the device as a Flash media to the computer, and accept writing a file, similar to what the nucleo boards do. Needs additional code, and would grow the bootloader, possibly taking another 16KB, but seems like a nice feature given the most common F4 have enough flash.
The backup register code is not really used in the Maple bootloader. Someone sent it to me, and I thought I may as well include it, but it also needed a change to the LibMaple core to set those registers prior to resetting – and I did not change LibMaple because from what I recall some people had concerns about the sketch using the backup registers ( as I think they used them in their sketch)- though I can’t remember the details.
Re:Bootloader overwriting its self
Yes. That needs to be fixed.
Found this interesting page on DfuSe
http://dfu-util.sourceforge.net/dfuse.html
Re:jump to sketch after upload
I think somehow the built in bootloader runs the code (from 0x8000000) after I upload the bootloader ( as I upload it via its own internal dfu )
So it looks like there is a process to do this.
It could be the Reset command sent from the host that does this, but it needs more investigation.
If this is the case, I thought we could potentially use the Backup register so that when a reset command was received, it sets a flag value, and the MCU is reset.
Then we can add code at the very start of the bootloader, that checks for this flag, and jumps immediately to the sketch
PS.
I think the Backup reg flag values that are in the bootloader are different to the values in the Maple bootloader, which is why I wondered if they were part of the STM code rather than something Chris added
PPS.
It’s strange if Chris wrote the bootloader to work with STM32GENERIC , because you can’t build the F4 version of STM32GENERIC with an vector offset, and I have asked Daniel about this, and will submit a PR to fix this.
But strangely there is an unused linker file for the Black F4 board with offset at 0x4000, already in the repo
Chriss offset is actually at 0x10000, which is the space reserved by STM example code. He didn’t change that part.
Chriss mentioned he wrote it for STM32GENERIC. He may have modified the core enough to fit his need. The bootloader is mostly unmodified from STM example except that it jumps to the user code after a timeout period, and I believe I didn’t see that in STM code.
I’m not 100 sure, but wouldn’t the STM32GENERIC load the VTOR redirect with whatever base address the sketch was compiled for? in that case if the linker script is modified to link in say 08004000, wouldn’t it load that address to the VTOR?
Otherwise he may have modified his copy of the core. In any case form what I saw in another thread, you have already identified what part of the core to change to allow for different offsets.
I think the parts we need to confirm/modify are:
1.- Ensure the bootloader doesn’t wipe itself (by mass erase of by writing to it’s page)
2.- Confirm it jumps to the sketch right after upload.
3.- Check and confirm if it supports the Reset command, and in that case that it will jump to the sketch.
Perhaps rather than use the backup registers, we could reserve the first word in RAM for a magic word.
We can do that thru the linker scripts, so variables, heap, etc start 1 word up. I don’t think that would hurt anything, and it will be a word that no one ever should try to modify, since if it was not reserved it wouild belong to a variable. We can do that thru the linker scripts, and only access it with a pointer to that address.
I totally agree with your list.
Make sure it doesn’t overwrite first etc
Re: Backup registers vs RAM
I thought there was some issue with RAM not surviving system reset, which is why everyone seems to use the backup registers
It could be the MCU clears its RAM when it gets soft reset e.g. nvic reset, and probably does the same thing from a hard reset in case the RAM started up with random values in it.
Re: VTOR and linker scripts
Its a bit odd, because there was already a linker script with the 0x4000 offset in the generic Black F4 variant folder, but I couldnt see anything in boards.txt that used it.
I’d expected to have to make my own linker file, like I did in LibMaple, but there was one already there with the correct value.
But the guard #ifdef was missing from the HAL startup file, so there was no way anyone could have built a version with a offset without modifying their local copy
Probably the best thing is to start a thread in the STM32 Generic section and I’ll also PM daniel to let him know
PS. I was going to do a PR for the guard #ifdef, but I’ve not done it yet, as I need to isolate that change from my boards.txt change and test it first, on my local machine
As I’m not sure Daniel will want a PR to add bootloader support until its all working
PPS.
I should also ask Frederic about implementing the same changes to STM’s core, as I suspect they have the same issue of the guard ifdef being missing
I’m not sure what you mean.
We were initially looking at resetting into the built in DFU bootloader in the F4, as there is code to do this, but it if the sketch crashes you need to set Boot0 to get into the bootloader again.
I know ultimately that using STLink etc is better, but most of the Generic boards don’t have onboard STLink and the bootloader on the F1 is very popular and works reasonably well, considering the lack of decent USB reset hardware on the generic boards
The code Victor is using, is STM’s own DfuSe example code with some additions to jump to the sketch
The downside of using the STM’s HAL code is that its much bigger than the LibMaple F1 bootloader, and also it needs the newer dfu-util which is not compatible with the Maple bootloader
I think that the F1 Maple bootloader can be modified to run on the F4 but it may require a lot of changes / time / effort, hence using STM’s own DfuSe HAL bootloader code seemed to be a reasonable option
The Cores don’t need a lot of modification to support using a bootloader, I already did some changes to LibMaple F4 to allow me to upload if I manually reset, and I also have the same thing now working on STM32 Generic
But I need to get the Cores to call nvic reset when they get the magic reset sequence and only STM32 Generic already has code to handle that (on the F4) – Libmaple F4 USB code is completely different to the F1 and would need a lot of changes to get the Magic number reboot working.
I think the same applies to STM’s own core… I’m not sure if they would be willing to make changes to the USB serial code to always check for the Magic sequence.
Hence why STM32 Generic looks the best initial candiate to add a flash based DfuSe bootloader
[RogerClark – Tue Aug 29, 2017 3:20 am] –
I know ultimately that using STLink etc is better, but most of the Generic boards don’t have onboard STLink and the bootloader on the F1 is very popular and works reasonably well, considering the lack of decent USB reset hardware on the generic boards
This is my point. The STM Core doesn’t have to jump through hoops screwing around with bootloaders. The boards it currently supports already have either an onboard ST-Link or Mass Storage copy upload features. You aren’t adding any value to those boards by offering a bootloader. You are only adding complications and headaches where none is required.
Most of the NUCELO boards don’t even have native USB connected to any external connectors. They provide a debug Virtual Com Port usually connected to USART2 pre-wired that just works.
I understand the push for Generic boards but you guys have the STM32 Generic and the libmaple cores for that.
[RogerClark – Tue Aug 29, 2017 3:20 am] – But I need to get the Cores to call nvic reset when they get the magic reset sequence and only STM32 Generic already has code to handle that (on the F4) – Libmaple F4 USB code is completely different to the F1 and would need a lot of changes to get the Magic number reboot working.
The “magic reset” thing bugs me as it is just a source of questions. “Why don’t I see a serial port on my blink sketch?” … “Why doesn’t my code upload after I load a blinky sketch?” All the magic reset does is generate a stream of slightly different questions that are all asking the same thing .. Why doesn’t the bootloader work?
Point taken re: STM’s own core
I have nothing to do with that development. I doubt they would want the magic number reset code, as it messes around with core code.
I was initially doing this for F4 LibMaple but it needs a load of changes to support the magic number reset
STM32 Generic already has the Magic Number reset, so it seems logical to extend the functionality to the F4
FYI.
I’ve been too busy with work etc, to do much on the bootloader.
But I think I’ll need to work out a way to debug it in real time.
I’ve found some HAL UART code, so I’m going to see if I can setup USART 1 (PA9,PA10) as a debug terminal.
I think that should be fast enough to print some message about the various commands that DFU receives from dfu-util
Alternatively, I’m considering just bit banging data out via a form of SPI, and using my logic analyser to view the SPI as text.
(This may be easier to get working than UART and also take far less Flash.)
But even if we need to make the bootloader a bit bigger for debugging, its not a problem, as we can just temporarily change the VECT OFFSET to a 0x6000 etc (and change the linker).
Then change it back, once the code is working and the UART code has been disabled.
PS.
Preventing the bootloader being overwritten should not be a problem.
The simplest solution is to change
Flash_If_Erase(…..) in usbd_dfu_flash.c and check what page of flash its trying to erase
And also change uint16_t Flash_If_Write(….)
So it doesn’t attempt to write to the pages either
BTW.
DfuSe is suppose to control the erasing and writing of pages separately.
If we get either of those functions to return 1, that should flag the error back to dfu-util
@Rick, the GENERIC and Libmaple cores already include the part managing the “magic” packet to reset, so there is not much if anything to add to them.
This is obviously not for Nucleo boards, I agree that’s pointless, this is for the bunch of F4 boards out there that have no stlink on them. Even if we skip managing the magic packet, having a bootloader that runs automatically and jumps to the sketch if no upload is done in less than X seconds is better than having to mess with the boot pins back and forward. Still, there is no obligation for anyone to use, it will be available for whoever wants it.
Personally I want to use it because as I try to use F4 boards in projects I want an easy way to update the code without having to plug a debugger or mess with boot pins, just plug a usb cable and reboot.
STM wrote the application and it works pretty good out of the box, only missing having a timeout in case of no upload, and re-enumerating USB, and it reserves way more memory than needed by default (64KB, while it fits in 16).
I wasn’t talking about the libmaple core nor the generic core. I’m talking about the official STM supported core.
I wonder if porting the Maple bootloader is still also an option.
Someone already posted code for this port to one of those pay-to-download Chinese sourcecode sites.
Now that we have several members in China, I may PM them and see if they know how to download that version
I am sure I searched for this before, but I just found this
https://github.com/gbulmer/openstm32sw/ … bootloader
Edit.
As a matter of interest I tried compiling that F4 version of the Maple bootloader, and flashed to my Disco F4, but although the LED flashed, nothing appeared on USB.
I suspect the code only works with an older version of GCC, as I recall we had optimization issues with the Maple bootloader (however I thought GCC 4.8 was OK)
In this case I was using GCC 4.8
So this does not work “out of the box” either
Also the aeoquad32 official page seems to indicate the bootloader in that board (based on F405) is the internal one. There are instructions to load the Firmware using DfuSE.
i agree, it may never have worked…
The code to flash the LED works, and it flashes at the correct speed, so the code for the PLLs and the GPIO etc must be OK, but it doesnt numerate USB.
i did try to find where the code came from, as the commit comment mentions ist from ala42 but that github account is completely empty.
i will PM gbulmer about it, to see if he cam shed more light on its status
PS. The reason I was looking at it was, that it should work with the existing dfu-util and bat files etc, also it compiles to less than 8k ( but size if not so important on the F4)
