Partial / old code for a F4 Maple bootloader

Guys

I just came across this site that claims to have code based on the Maple bootloader, which works for the F4

However , it doesnt seem to be possible to download the code without logging in, and it looks a lot like those file sharing sites which charge for download
(and its possibly based in China)

http://www.codeforge.com/article/304217

Anyway, as there is significant interest in the F4, with both @danieleff’s core and STM’s core, but uploading via the built in bootloader being problematic, I think if we could get hold of the f4 bootloader code, it would be handy.

That being said, I’m not sure there would be much difference between the F1 and F4 bootloader code. The main differences would be the MCU setup including PLL, and also the register addresses of all the hardware.
There may be other differences between the low level USB control on the F1 and F4, but possibly not that much.

in the mean time, but this is just for the f4 black vet6 board, there are 4 ‘buttons’ on the board itself, the *sketch* can use those buttons for a different purpose.

then some references:
stm32 f4 reference manual rm0009
http://www.st.com/content/ccc/resource/ … 031020.pdf
victor is the one who pointed this out in a thread
9.2.1SYSCFG registers for STM32F405xx/07xx andSTM32F415xx/17xx
9.2.1 SYSCFG memory remap register (SYSCFG_MEMRMP)
This register is used for specific configurations on memory remap:
• Two bits are used to configure the type of memory accessible at address 0x0000 0000.
These bits are used to select the physical remap by software and so, bypass the BOOT
pins.
• After reset these bits take the value selected by the BOOT pins. When booting from
main Flash memory with BOOT pins set to 10 [(BOOT1,BOOT0) = (1,0)] this register
takes the value 0x00.


@ag123

On Windows I have a lot of problems with the built in DFU, which really make it unusable for me

I think ST use there own / special version of dfu-util, which has extensions that they use, but which are not in the version of dfu which we have for windows.

Additionally, I’ve read that people seems to have problems loading the driver and need to use ZaDiag (though I didnt have that problem)

The only way I could upload via DFU was using STM’s own upload program, which required the file to be in a special format (arrggghhh)

So I’ve given up on that.

Re: Resetting the USB, the sketch code could do that like it does on the F1, by changing the USB D+ pin ( I forget if its PA13 or PA14) to GPIO and driving it low for a short time, before changing it back to floating / USB operation.

However, overall, I think we’d be better off with F4 version of the Maple bootloader.

RogerClark wrote:Guys

I just came across this site that claims to have code based on the Maple bootloader, which works for the F4

However , it doesnt seem to be possible to download the code without logging in, and it looks a lot like those file sharing sites which charge for download
(and its possibly based in China)

http://www.codeforge.com/article/304217

Anyway, as there is significant interest in the F4, with both @danieleff’s core and STM’s core, but uploading via the built in bootloader being problematic, I think if we could get hold of the f4 bootloader code, it would be handy.

That being said, I’m not sure there would be much difference between the F1 and F4 bootloader code. The main differences would be the MCU setup including PLL, and also the register addresses of all the hardware.
There may be other differences between the low level USB control on the F1 and F4, but possibly not that much.

i’m using dfu-util from sourceforge (v 0.9 but i’d think the lower versions works as well)
http://dfu-util.sourceforge.net/dfuse.html
it works with st’s DFU on f4, i’ve been flashing / testing various sketches / f4 cores that way pretty recently

unfortunately, as it is i’m working in linux. i’d need to setup the usb stack to test the same in windows 7 if i need to test that.

@ag123

I did try that once before on Windows with no success. But I will try again.

it seemed dfu in windows is somewhat more troublesome due to various different dependent components being needed. Accordingly there is a ‘driver stack’ needed in addition to additional configurations partly because dfu-util uses libusb which in turns uses winusb. this driver stack seem to be apparently winusb <- libusb <- dfu-util

some of the links found are as follows:
https://github.com/libusb/libusb/wiki/Windows
http://zadig.akeo.ie/
https://msdn.microsoft.com/en-us/librar … 40196.aspx
https://msdn.microsoft.com/en-us/librar … 40174.aspx
http://dfu-util.sourceforge.net/

i’d think it would probably be wise to try to backup the related driver components and even relevant registry parts if possible as the steps may likely involve un-installing existing drivers and re-installing new drivers perhaps using zadig

apparently this post by pito show some hints, it seemed that libusbK (which is an open sourced implementation of WinUSB) needs to be installed (e.g. via zadig) to use dfu-util v0.9
http://www.stm32duino.com/viewtopic.php … 188#p26207

on the black stm32f407vet6 board
http://wiki.stm32duino.com/index.php?title=STM32F407
it is found that ST’s dfu bootloader do not do a usb-reset even if the boot0 jumper is set and reset is pressed.
hence pito’s comment that it is necessary to unplug the usb cable and replug that after setting the boot0 jumper
i’m not too sure about other boards though

i noted that boards like stm32f4 discovery has an onboard st-link
http://www.st.com/en/evaluation-tools/s … overy.html
i’m not sure if this probably mean that the default usb port can only be used for st-link and not usb
but according to the thread discussing the stm32f407vet black board, st-link seem to be a more effective way to install sketches as it doesn’t need any meddling with the boot pins, just that usb-serial would probably be to use ‘the other port’ on the board
http://www.stm32duino.com/viewtopic.php … 188#p26207

hope this helps

@ag123

umm. I may try on a different Windows machine, but I’m not keen on messing up my existing drivers by using ZaDiag etc etc

Hence the reason why I was looking for a better overall solution for Windows users by having a F4 version of the F103 bootloader

I’m sure it should be relatively simple to modify the existing bootloader, but I don’t have time to do it at the moment.

in the prior thread discussing the stm32f407vet6 black board
http://www.stm32duino.com/viewtopic.php … 188#p26207

the prevailing thoughts seem to be that st-link is possibly more practical and convenient doing sketch installs etc as meddling with boot pins etc and that (lack of) usb reset proved troublesome

however, we are bound to get ‘users’ who simply get that board but do not have an st-link. hence, the thoughts are that if those ‘users’ are willing to make do with dfu despite the inconvenience they could meddle with the boot pins, disconnects etc and use dfu to install the sketches or just about any firmware

as for myself, i ‘worked around’ the (lack of) usb-reset by using a utility in linux that does that usb-reset. hence, it saves me a little trouble as other than meddling with the boot pins, i don’t need to literally unplug / replug the usb cable
—
the bootloader is nevertheless a good idea though, as it would save all the trouble of meddling with boot pins and we can issue the usb reset if we need to

I thought it should still be possible to upload a bootloader on the F4 via USB to Serial like the F1.

Re: Messing around with boot pins.

I thought there may be a way to jump to the built in DFU bootloader from code, though I’ve not tested it

https://stackoverflow.com/questions/282 … 2#28288454

But I still think the whole messing around with ZaDiag even on W10 will put a lot of people off.

Hence if we had a bootloader like on the F1 it would be a lot less hassle for everyone

RogerClark wrote:Hence if we had a bootloader like on the F1 it would be a lot less hassle for everyone

I did some research on this today, and tried to register (using a temporary email address) with the site that had the F4 libmaple bootloader, but the site appears to be broken, so I don’t think there is much hope of getting that code.

I also found a bootloader for a PX4 flight controller board, which uses the STM32F4, and managed to build it, and upload to my F4 Black board, but it didnt enumerate on USB.

https://github.com/PX4/Bootloader

The code uses LibOpenCM3, which seems good, however I didn’t look into detail of how the bootloader worked, I just wanted to test if it was possible to use some existing code and modify it.

I think the PX4 code can be run on the F4 discovery, but I didnt try that

https://pixhawk.org/modules/stm32f4discovery

Also, I’m not sure what the bootloader does really

Edit.

I just found the schematic for the PX4 https://raw.githubusercontent.com/PX4/H … v2.4.5.pdf

and it looks like the USB connector is on the OTG pins (well thats what they are labelled)

Which would explain why the bootloader didnt work with the Black F4 board, as I think the USB connector is on the primary USB pins not the OTG

Those pins labeled as OTG_FS_DP/DM are the “normal” USB pins on PA11/12, similar to black F4.

took a look a the px4 boot loader codes on github, it seemed to give me an impression it is a uart bootloader, but i’m not sure though
nope incorrect it seem to use a serial protocol to download / flash the image
https://github.com/PX4/Bootloader/blob/master/bl.c#L524
and it seemed usb-serial cdc-acm is supported

found something interesting here, i’ve not tried it though, jumping to stm32f4’s internal dfu bootloader
https://github.com/microready/STM32F4_DFU_Demo

i think there is a thread somewhere here which off-hand i couldn’t find in which victor mentioned it is possible to set the ‘software boot pins’
i.e. we can set Boot0 using some registers and do a reset, then it’d drop into dfu mode
that may well be a short cut to do a dfu-boot loader but you would need to resolve the st’s dfu’se issue on your desktop
and in addition we still need to fix the ‘no usb reset’ issue with stm’s dfu boot loader

rm0009 f4 reference manual
http://www.st.com/resource/en/reference … 031020.pdf
page 291 9.2 SYSCFG registers for STM32F405xx/07xx and STM32F415xx/17xx
9.2.1 SYSCFG memory remap register (SYSCFG_MEMRMP)
This register is used for specific configurations on memory remap:
• Two bits are used to configure the type of memory accessible at address 0x0000 0000.
These bits are used to select the physical remap by software and so, bypass the BOOT
pins.
• After reset these bits take the value selected by the BOOT pins. When booting from
main Flash memory with BOOT pins set to 10 [(BOOT1,BOOT0) = (1,0)] this register
takes the value 0x00.

and this design would probably mean we either need to wait for a button press on the board
or a utility is needed on the desktop to send a command over say usb-serial during during the reboot which would trigger the dfu mode
this would be tricky as well because 2 separate utility would be needed in close co-ordination
a utility to send a usb-serial command and dfu-util to upload the sketch after reset
———-
another way though is we utilise an ‘extra’ button on the board in the libmaple core codes so that if that button is pressed, it would reset and go into dfu-mode. an extra compile define is likely needed
—
2 addition ones from google search
https://github.com/hooao/stBooter
^^ this seem to be doing an upload using some ymodem protocol, uart based
https://github.com/RdMaxes/stm32f4_Seri … bootloader
^^ this is similar doing an upload using some ymodem protocol, uart based

@ag123

Thanks for looking at that bootloader.

I will need to try it in another of my F4 boards as it does not enumerate at all on my Black F4 board.
But my Black F4 board is the smaller one. ( I will take a photo later)

Uploading via USB Serial rather than DFU is not necessarily a problem, depending on what the protocol is. I recall @jwc wrote a bootloader for the F1 which used the same serial protocol that is built into the Arduino IDE.

I suppose it may be slower than DFU, but I think the limiting factor when uploading is the time erase and write to flash, rather than the transfer speed from the host.

Re:booting into the built in DFU bootloader.

I found and posted some links to code to do that, but it doesnt solve the problem on Windows that getting DFUSe to work is a pain and requires seriously messing around with the driver install.

So I still prefer the option of our own bootloader.

Own solution is good.
What about including a “flasher” to the normal F4 code? A bootloader always included to the user app.
F4 has anyway lot more code space than F1 so this would not be a problem. It could run from the RAM.
The software could detected the “magic sequence”, then just call the flasher which is then receiving the code from the host, and programs it into the chip.

EDIT
– On critical point here is that, according to my experience on F4 USB serial, the current implementation seems to loose sometimes some bytes and/or hangs if lot of data is transferred. We had similar issue on F1, but because here the code is different, we need to investigate separately the problem.
– The other point is that the flasher app must run from RAM, otherwise it could delete himself on-the-fly. I think Rick (or was it Pito?) has a solution how to let apps run from RAM, so this know how could be used here.
– Additionally or alternatively, we could use a two stage flasher: the first stage loader loads the flasher app (second stage) via USB serial to RAM and then let the second stage flasher app run from RAM. This will receive the new code via USB serial. The first stage loader can/should be very thin so that not much resources are wasted during normal run. Of course, the first and second stage loader RAM map should be defined to avoid overlap each other.

there is another scenario where the flasher could live at some ‘high memory’ address so that when the ‘magic sequence’ is received on serial-usb, we can jump to the flasher. but this still has a catch in that USB serial possibly always need to be initialised as disabling usb_serial possibly means disabling access to the flasher as well.

ag123 wrote:there is another scenario where the flasher could live at some ‘high memory’ address so that when the ‘magic sequence’ is received on serial-usb, we can jump to the flasher. but this still has a catch in that USB serial possibly always need to be initialised as disabling usb_serial possibly means disabling access to the flasher as well.

agreed, having the bootloader separate would help avoid many tricky situations than if we bundle a flasher in the core

i’m thinking in terms of ‘porting’ the existing stm32duino boot loader into f4. in that sense it would be much easier to integrate in the core. we won’t need to have another app on the host side to do the sketch install as we’d need to think in terms of several platforms windows, macos, linux.

i think currently there is a utility that does this special usb-serial reset sequence:
http://docs.leaflabs.com/static.leaflab … 3-rev5-dfu
1) Pulse DTR (high and then low, so that you’ve created a negative edge)
2) Write “1EAF” in ASCII over the serial pipe


Yep. No hurry.

Its just a shame that there was a working port of the F1 bootloader to F4 but we have no way to get to the code as its on a defunct chinese language website.

I guess I could try PM’ing the 2 or 3 chinese users on the forum and see if they could investigate, as they may be able to figure out if the code is available elsewhere in Chinese

it seemed @jcw dropped a tip here
http://www.stm32duino.com/viewtopic.php … =70#p28847
https://github.com/jeelabs/embello/tree … s/usbserup
he has got a usb-serial boot loader that uses stm’s serial boot protocol that’s installed in ‘high mem’

i think this is fairly feasible to adapt for f4 e.g. instead of dfu we could use serial. but nevertheless as with any s/w project this would take some time & effort to port even if it seem superficially ‘easy’. for one thing the usb hardware on f4 is still different from f1. we’d need to start with a different usb hardware ‘driver’ to begin with.

given the comparisons, we might as well go slow and do a maple dfu bootloader instead. in that sense it would be an extension of the current maple style dfu boot loader that works similarly for both f1 and f4. and one of the issues that it alleviates is the host side dfu and usb driver stack and utilities which could have their own host side issues. hence starting with rather mature tools on the host side may save some troubles with integration into the core

Thanks

I knew @jcw had done a high memory bootloader. He may have even started it as a low memory bootloader (it may be worth a look in the commit history)

It had occurred to me that it could be adapted for the F4 as it uses LibOpenCM3 which has F4 support; so its definitely an option.

I though that he used the same upload protocol as used by the AVR boards (I forget what is called), but perhaps he changed to using STMs serial bootloader format (or never got the AVR upload protocol working)
We’d need to ask him

Wouldn’t it be easier for the user to have a mass storage drag&drop .bin to the usb drive style flasher? (like mbed). No need to install usb drivers.

Yes. That would be fine as well, though I suspect people would need to install the serial drivers sooner or later, e.g. using STM’s own drivers or using the hack we use for Libmaple

But I agree, USB mass storage is worth investigating, especially if it can have a unique name so that the uploader can enumerate the drives and find it without the user having to select it (like we did with the Nucleo uploads to the STLink mass storage)

But the USB MSC (mass storage) is also part of the user app, right? In this case we have again the upload problem when user app hangs.
Anyway, I would welcome MSC as bootloader option, too.
However, DFU seems to me the quickest implementable option for the time being, with less effort than combined with MSC.

a ‘mass storage class’ installer is attractive just that the feel is it would be a somewhat bulkier. in addition serial or dfu protocols seemed somewhat ‘easier’ to write & is more designed for purpose. i’m thinking of going with maple style dfu mainly as this would likely make it ‘easier’ to integrate with the existing core using the same tools and scripts

On the subject of a Mass Storage bootloader.

I came across this video (in Russian) today, when replying to a question from someone on youtube

https://www.youtube.com/watch?v=Q1r8yxknQh4

It links to this page (in Russian) http://www.avislab.com/blog/stm32-bootloader_ru/

Which links to this code in GitHub https://github.com/avislab/STM32F103/tr … Bootloader

The code seems to contain a binary for the F103, but I’ve not had time to try it yet

I’ve tried it, but the binary in github does not eumerate on USB for me.

Edit.

PB1 needs to be pulled low, otherwise it doesnt seem to start its USB Mass Storage

I presume is PB1 is high it jumps to 0x8003000, but I’d need to double check.

The other thing I’ve noticed, is that I don’t think the code supports the FAT file system, as the author was using the Win32 disk imager program to write raw data to the device.

On the topic of mass-storage bootloaders, it would be neat to make one that supports the new UF2 format.
UF2 essentially takes the concept behind hex files where you have records of address+data, only it delimits them by 512-byte sector boundaries instead of line breaks so that each record is guaranteed to be written atomically, even if it’s written out of order.

Compared to most demo mass-storage bootloaders out there, a UF2 mass storage bootloader should work on all of the major OSes.

Here’s a blog post that goes into more detail:
https://makecode.com/blog/one-chip-to-flash-them-all

Apparently their (Atmel) SAMD version of the UF2 bootloader fits in 8KiB, which is pretty impressive, since I can barely fit a regular DFU bootloader in 8KiB.

That USB Mass storage version seems to take about 9.5k, though I think its possibly not optimised, as it is in a folder called debug e.g. its likely to be a debug build

the problem with usb mass storage protocol is that in a normal sense the device is simply presented as a *block device*.
the (FAT) file system is completely handled by the host o/s which could involve updating directory entries, cluster maps and bit maps. the host could literally try to ‘write anywhere’ on the device, it may choose to write additional files, meta-data (e.g. vfat entries) etc
this would not only make the task of writing a flash installer more complicated and it would likely introduce bugs / incompatibility across different platforms, e.g. the host can be a windows pc (there are lots of windows versions), macos (again many different os versions), linux pc (again many different kernel versions) and android phone, and iphone etc. all of them may handle fat file systems somewhat differently.
hence, usb mass storage for firmware update isn’t quite ‘driverless’ it is likely ‘programmed to interpret a particular host os protocol of handling fat file systems’, this is a major trouble spot for firmware updates, it may work on one platform and break on another say it works on linux and breaks on windows etc.

hence, a ‘designed for purpose’ protocol is more appropriate for this purpose, DFU is one of them. we could also implement ST’s serial boot loader protocol
but given DFU is a ‘pretty standard’ protocol it would be good to continue to use it as it has been used with the original maple (mini)
currently the open sourced utility dfu-util does the install on the host side which support ST’s DFUSe’s protocol as well which allows specifying the *address* to install to
http://dfu-util.sourceforge.net/
this is pretty much ‘adequate’ as a ‘driver’ on the host side. for all you know, given the increasing prevalence of these devices, ‘standard’ DFU drivers may make their way into Windows, Mac, Linux and other platforms
it isn’t too difficult to anticipate that ‘firmware programmable’ usb peripherals, e.g. mouse, keyboards, any usb gadgets etc may become common technologies and that DFU or possibly DFU with some enhancements e.g. DFUSe become a common protocol for all that

there is actually another usb protocol fastboot by google android, but it would seem that fastboot may be rather bulky to implement on a low flash, memory mcu
https://android.googlesource.com/platfo … /fastboot/

just 2 cents

I had another thought about where we can get a F4 DFU bootloader, and it seems that the BlackMagic probe used to have a F4 version of their DFU bootloader, but it was removed in this commit

https://github.com/blacksphere/blackmag … c9fc53f5d6

If I get time I’ll try checking out the previous commit and see if it compiles for PROBE_HOST=f4discovery as that target is supposed to build as the F4 being the BMP device

Note. I did try to build the latest version, for the f4discovery, as this is supposed to provide the core of the BMP functionality (but not DFU)
However the USB didnt seem to work for me at all when I did this.
I tried both a my Discovery F4 and also a generic F407 board but neither enumerated on USB
So I don’t understand why this is not working at the moment, because the guys on the BMP gitter chatroom thought it should work.

Roger, did you try the raw binary for F4 disco? http://builds.blacksphere.co.nz/blackmagic/

Does this mean that we could turn a black F4 board into a BMP probe? It sounds interesting.

Yes. Its supposed to turn a F4 board into a BMP. (according to the guys on gitter) I looked at the makefile and it does build for cortex m4 so it does look like it should target the F4

But, I tried building my own binary but it didnt seem to work on either my F4 Discovery board or my generic F407 board

I will try flashing the pre-built binary onto my Discovery F4