Try for fast jumping between bootload and application

[Christoph Eschenbach]

Posted on June 05, 2018 at 13:05

Hello there,

i am working with STM32429VI.

For my device i try to implement a simple bootloader which gives me the possibilty for DFU.

DFU works fine and everthing else too.

But I need some feedback if this is a attempt which ain�t gives me problems in the future.

My bootloader:     0x0800 0000 - 0x080 7FFF

Application:          0x800 8000 ...

Since i will have no reset button on my later hardware i want somehow jump back to the bootloader from my application and hold it in the bootloader until i upgraded the application.

For this i reserved a small part from the RAM: 0x2000 0000 - 0x2000 001F

For both the bootloader and the application i set the ram in the linker file to begin at 0x2000 0020.

Inside the small part of the RAM i write a specific value, if the application executes a specific function.(Basically i can send a request from outside to the mcu and it will execute the write function and do a reset).

By this the bootloader starts and reads out the specific value and holds the bootloader mode until the new firmware has been downloaded the value gets reset to default and a system reset is executed. So the bootloader starts again but jumps then to application.

This way I can avoid that the usb is configured all the time as DFU and I have a clean start for the bootloader and the application.

This works fine for now.

My Application is working with freertos and i think that the rtos could mybe access this part of the RAM somehow, but i am not sure. I hope excluding this part of the RAM in the Linker-Files will terminate any excess from the RTOS.

I am not that experienced in writing a bootloader and hope someone can give me a feedback if this is done well or if this can lead to a bunch of problems.

Thank you in advance

Christoph

#dfu #stm32f4 #linker #ram #freertos #stm32f429 #bootloader

[AvaTar]

Posted on June 05, 2018 at 13:48

By this the bootloader starts and reads out the specific value and holds the bootloader mode until the new firmware has been downloaded the value gets reset to default and a system reset is executed. So the bootloader starts again but jumps then to application.

I'm using a similar method on another Cortex M based device (not ST, sorry ...).

But it seems you didn't consider the 'rainy day' scenario - the firmware update fails consistently, or is corrupted.

Our application has a customer-specific header including a checksum, and the bootloader calculates the checksum over the application each time, and remains in the BL if both values don't match.

You might consider a fall-back variant, which doesn't make things really easier.

My Application is working with freertos and i think that the rtos could mybe access this part of the RAM somehow, but i am not sure. I hope excluding this part of the RAM in the Linker-Files will terminate any excess from the RTOS.

My device uses a more expensive external MRAM, but some thousands of other paramters need to go there as well.

[Christoph Eschenbach]

Posted on June 05, 2018 at 17:24

Hello AvaTar,

Our application has a customer-specific header including a checksum, and the bootloader calculates the checksum over the application each time, and remains in the BL if both values don't match.

This is a method i really should consider too. Thanks for the advice.

You might consider a fall-back variant, which doesn't make things really easier.

I have a second flash bank left empty for now where i could store the parent application before upgrading.

Well nothing what we do is really easy and the affort is our experience, which will make thinks easier later.

I really appreciate your information.

Thank you very much for your fast response.

[taraben]

Posted on June 05, 2018 at 23:40

Hi Christoph,

check this out: MCUBoot

https://www.zephyrproject.org/presentations/zephyr-and-mcuboot-as-foundations-for-secure-iot-products/

 

I think you also ancounter the problem that getting the new firmware requires to erase the old first.

Because the flashsize exceeds the RAM Size.

Think about having an alternative intermediate memory for the application. i.e external SPI flash.

I loaded completely then swap applications.

Some bootloader work with two applications in FLASH but then the application need to become address independent.

my 2ct.

Adib.

--

[AvaTar]

Posted on June 06, 2018 at 07:33

I have a second flash bank left empty for now where i could store the parent application before upgrading.

Well nothing what we do is really easy and the affort is our experience, which will make thinks easier later.

The only problem - both Flash banks have different addresses, and thus need the application built explicitly for it.

And, as adib said:

I think you also ancounter the problem that getting the new firmware requires to erase the old first.

Because the flashsize exceeds the RAM Size.

You will most likely encounter this problem with every MCU. The new firmware needs to be downloaded and flashed in segments, while the old is erased at once.

[Christoph Eschenbach]

Posted on June 06, 2018 at 09:46

Think about having an alternative intermediate memory for the application. i.e external SPI flash.

I loaded completely then swap applications.

Unfortunately the hardware I use dont uses any external flash.

Some bootloader work with two applications in FLASH but then the application need to become address independent.

Well FreeRTOS is working with dynamic memory allocation and I avoid static functions and variables. So far I see no problem with address independence.

I know static allocation is the safest way, because of deterministic. But takes alot more affort.

And I have found out that FreeRTOS only access the RAM which is set in the linker-file. So far I should be save from the RTOS to overwrite my reserved RAM section.

So If it is overwritten I have done it somehow in my source code.

The only problem - both Flash banks have different addresses, and thus need the application built explicitly for it.

I thought of copy the old application into flash bank 2 as backup then eares bank 1 and load the new firmware into flash bank 1.

If then something is corrupted the old application will moved back to flash bank 1.

In the dfu example from st I take a bin-file add a starting address for this file and generate a .dfu-file out of it.

Or I take a .hex-file which already has added the starting address.

Does this makes it impossbile to copy it?

Back to the bootloader stradegy: I fear most that with this stratedgy I could end up that the bootloader always tries to jump to application.

And I forgot to implement or I implemented a failing function which doenst that the variable in the RAM correctly. This would mean the bootloader wouldnt be hold the DFU mode.

[Christoph Eschenbach]

Posted on June 06, 2018 at 10:20

So if this DFU-Flag is not corrupted by application (the value stored in RAM) and a valid code/checksum exists too. I will have the problem if my application do not have any function to set the DFU-Flag, I wont be able to run dfu mode again.

Even if I secure that this function to set the Flag is inside the application it could be broken or someone made a mistake in the program there is no possibility to run dfu mode again.

[AvaTar]

Posted on June 06, 2018 at 10:23

I thought of copy the old application into flash bank 2 as backup then eares bank 1 and load the new firmware into flash bank 1. If then something is corrupted the old application will moved back to flash bank 1.

That would certainly work, but usually the project management does not like the expensive idea of reserving half of the Flash.

Back to the bootloader stradegy: I fear most that with this stratedgy I could end up that the bootloader always tries to jump to application.

The effort and safety you put into a bootloader should be justified by requirements of the device, and the update environment. The device I mentioned controls the movement of several metric tons of steel, so it must NEVER EVER get out of control, or people might die. A 'bricked' device is safer than a corrupt device.

Updates in my scenario are under direct human supervision, i.e. there needs to be a cable attached, and a (trained) person doing a sequence of manipulations. An update always happens with already existing application.

And I forgot to implement or I implemented a failing function which doenst that the variable in the RAM correctly. This would mean the bootloader wouldnt be hold the DFU mode.

Only a proper implementation and  appropriate tests will help here.Try the 'dumb' scenarios as well, i.e. the user pulls the power or USB plug during erase and during program.

[AvaTar]

Posted on June 06, 2018 at 10:26

I don't know details about your application, environment, and device access during update.

But the 'DFU flag' could be also be a jumper on a GPIO pin, or something similar.

[Christoph Eschenbach]

Posted on June 06, 2018 at 11:22

Only a proper implementation and  appropriate tests will help here.Try the 'dumb' scenarios as well, i.e. the user pulls the power or USB plug during erase and during program.

Yes for sure. Things I haven´t concered, but should be part before every release of a firmware update.

That would certainly work, but usually the project management does not like the expensive idea of reserving half of the Flash.

My advantage or maybe disadvantage is that I am the projectmanagement.

For now the application doesnt even touches the half of the first flash bank and I don´t think it will sometimes. But I get your point.

This was the first idea how to fall back to a running system if the firmware update fails.

The device I mentioned controls the movement of several metric tons of steel, so it must NEVER EVER get out of control, or people might die.

Luckily I have not that kind of critical enviroment.

A non-working device could 'only' cause a loss of production for our customers which could lead to huge loss of sales or penalties for not delivering in time.

So I always have to be sure the device runs again after a certain of time.

The DFU is only the 'small part' of the bootloader. The considered bootloader will have the possibilty to flash over ethernet, which will be my next task.

For our most customers it is important that firmware updates run automaticly over a service and if possible not even with human interaction. They will have many devices in network. And I need that they have trust in our product and that its easy to handle.

But the 'DFU flag' could be also be a jumper on a GPIO pin, or something similar.

I will keep that in mind if I will update the hardware. But the 'free' GPIO´s are tied to a connector. I could bridge a GPIO to ground by the connector but this isn´t really a solution for me at the moment. As you said I need to have to be sure that these parts of the application runs correctly in the test phase.

This will improve my further development very much.

I hope people will experience same by reading your post.

Thank you very much for your feedback your advices, and above all your time and involvment.