Custom bootloader guidance

RE: Custom bootloader guidance

Thanuha — Tue, 02 May 2023 17:05:37 GMT

I have a 1 query here, If I use DFU Bootloader of Nordic, how can I update the F/W from the same app which we are also developing for our application. we needs to maintain 1 separate app for the f/w update and also we don't have any pins in device for going in bootloader mode again.is my understanding correct?

we are designing the Product and for that mobile application is also there. weather this will be good approach or we needs to develop our own custom bootloader?

RE: Custom bootloader guidance

Einar Thorsrud — Thu, 09 May 2019 12:32:02 GMT

Hi,

[quote user="MStampe"]- I would have two projects right? One for bootloader/DFU implementation and one for our application?[/quote]

Yes, that is correct.

[quote user="MStampe"]- As for production, we need both of these modules in one hex file to program the device before entering the field.[/quote]

Yes, and you also need the MBR or SoftDevice hex (which depend on if you need BLE transport or not), and you need a valid DFU settings page. Everything can be merged into a single hex file used for production programming.

[quote user="MStampe"]- Afterwards we need to generate application only hex files, which can be transfered to the DFU through ESB.[/quote]

Yes.

[quote user="MStampe"]What I am not able to understand is the relations of how the different project outputs will be correct, regarding addresses, starting addresses etc?[/quote]

Please refer to the bootloader documentation, particularly the Memory layout.

RE: Custom bootloader guidance

MStampe — Thu, 09 May 2019 08:53:37 GMT

Hi Einar

Thank you for the detailed answer, and the clearification of the DFU and bootloader relation.
I think I will stick to your suggestion and use the examples as a starting point, and then implement the ESB transport layer myself.

The first practical questions that comes to mind, and the last I think I need to understand before I can complete the implementation is:

- I would have two projects right? One for bootloader/DFU implementation and one for our application?

- As for production, we need both of these modules in one hex file to program the device before entering the field.

- Afterwards we need to generate application only hex files, which can be transfered to the DFU through ESB.

What I am not able to understand is the relations of how the different project outputs will be correct, regarding addresses, starting addresses etc?

RE: Custom bootloader guidance

Einar Thorsrud — Thu, 09 May 2019 08:39:12 GMT

Hi,

I want to start by commenting on a misunderstanding: Bootloader and DFU are very much related. The only purpose of the bootloader in the nrF5 SDK is to facilitate DFU. In other words: if you want to support DFU, you need the bootloader. If you don't need DFU, there is no point in having a bootloader.

It seems to me like what you want is the SDK bootloader, but with an ESB transport. We do not provide an ESB transport layer, but the bootloader is modular, so you can implement it yourself. If you want to save time and have available flash size, then perhaps you can stick with BLE for the bootloader even though you do not use it for the application. In that case you can use the example bootloader out of the box without any modifications. I believe much of these questions will be answered in a good way by reading bootloader documentation and experimenting with the DFU examples. DFU is quite complex so I strongly suggest you go with this approach, and use as much of the SDK examples as you can. If not, you risk spending a lot of time making something that does not work very well.

[quote user=""]- How to I setup a bootloader project in Segger, which are able to startup directly into the bootloader?[/quote]

I recommend you just start off with a example bootloader project. This will have everything in place. The boot up sequence will be the following (ignoring the special handling when here is a SoftDevice or Bootloader upgrade in progress):

MBR always runs first. MBR checks if there is a bootloader present (by checking the a reserved UICR register for a bootloader start address and/or a special word in the MBR).
If a bootloader is not detected, the MBR starts the SoftDevice if present, or the application (whatever is located at address 0x1000).
If a bootloader is detected, the MBR will forward execution to the bootloader.
The bootloader will check if it is supposed to enter DFU mode (via a number of configurable methods, such as GPIO pin asserted, retention register set, ...)
If DFU mode is not requested, the bootloader will check if a valid application is present and start it.
If DFU mode is requested or a valid application is not present, the bootloader will enter DFU mode.

[quote user=""]- How to setup a segger project with the correct flash placement for use with a bootloader?[/quote]

I assume you are asking about application in this case? As you can see from the memory layout, the bootloader is placed right in the end of the flash. Additionally, the linker will try to place tings in the beginning of the flash you have configured, therefor most applications does not need any modification at all. If you want, you can adjust the size of the application in the linker settings to make it clearer, but it should not have any practical consequences (other than that it will generate a linker error in case the application grows too large, so that it overlaps with the bootloader).

[quote user=""]- How to jump from bootloader to the application?[/quote]

Please refer to the bootloader implementation. You can see how it is done in nrf_bootloader_app_start() in SDK 15.3. (components\libraries\bootloader\nrf_bootloader_app_start.c), including the implementation of nrf_bootloader_app_start_final().

[quote user=""]- Will the UICR values be kept between bootloader and application, when not using the DFU?[/quote]

The UICR is a persistent (flash) register that typically never changes. Moreover, it cannot be deleted without erasing the full UICR page, which is typically something you never do in the field with an end product.

[quote user=""]- How would we write to the application flash from our bootloader? Using the fstorage or other lib?[/quote]

Please refer to the example bootloader (which use fstorage). I would like to repeat the strong recommendation to use the example bootloader instead of implementing this yourself.

Br,

Einar