F4 DFU bootloader

Post here first, or if you can't find a relevant section!
User avatar
RogerClark
Posts: 6893
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F4 DFU bootloader

Post by RogerClark » Tue Aug 29, 2017 2:52 am

Hi Victor

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

User avatar
Rick Kimball
Posts: 1011
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: F4 DFU bootloader

Post by Rick Kimball » Tue Aug 29, 2017 3:09 am

Roger wrote: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
Can we not suggest clogging up the ST Core USB with goofy USB reset logic. That is the one thing I think it has going for it. It isn't hampered by all the code for DFU reset. I know it supports non Nucleo/Discovery boards but my hope is that if you want a decent HAL core implementation that is focused on use with ST-Link or the Mass Storage option available on the Nucelo boards, the ST core is the one you go to.

I really dislike all custom flash based bootloaders.
-rick

User avatar
RogerClark
Posts: 6893
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F4 DFU bootloader

Post by RogerClark » Tue Aug 29, 2017 3:20 am

Hi Rick

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

User avatar
Rick Kimball
Posts: 1011
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: F4 DFU bootloader

Post by Rick Kimball » Tue Aug 29, 2017 3:53 am

RogerClark wrote:
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 wrote:
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?
-rick

User avatar
RogerClark
Posts: 6893
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F4 DFU bootloader

Post by RogerClark » Tue Aug 29, 2017 4:38 am

Rick

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

User avatar
RogerClark
Posts: 6893
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F4 DFU bootloader

Post by RogerClark » Tue Aug 29, 2017 10:48 am

Victor

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

victor_pv
Posts: 1648
Joined: Mon Apr 27, 2015 12:12 pm

Re: F4 DFU bootloader

Post by victor_pv » Fri Sep 01, 2017 4:39 pm

I will see if I can work some time on this this weekend. I think those are the key changes.

@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).

User avatar
Rick Kimball
Posts: 1011
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: F4 DFU bootloader

Post by Rick Kimball » Fri Sep 01, 2017 4:59 pm

All my comments were an attempt to plead you to "Please leave Fredic and the STM Core alone, the USB is going to be great" * or at least it will be implemented without needing any USB magic reset code : ) *

I wasn't talking about the libmaple core nor the generic core. I'm talking about the official STM supported core.
-rick

User avatar
RogerClark
Posts: 6893
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F4 DFU bootloader

Post by RogerClark » Fri Sep 01, 2017 9:44 pm

just to complicate things ;-)

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

User avatar
RogerClark
Posts: 6893
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F4 DFU bootloader

Post by RogerClark » Fri Sep 01, 2017 9:46 pm

this is so wierd...

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 :-(

Post Reply