how to FW update via bootlaoder with nrf52832

[ziv123]

Hello Nordic

I am using nrf52832, skd 16.0 , s132 v7, the data with the new FW will be delivered via UART

I wish to understand some issues regarding FW update, after doing some reading

first, if there is an example for a non secure FW update (we have no security issues in our project), for the soc i am working on because i saw there are only examples for 10056 and 10059 and not for 10040 with s132 (with no security that is) ? 

1. First how is it located in memory ? there is a section for the bootloader, section for the softdevice and section for the app? How can I know the address or do I actually don't need to know        them ?

2. When updating FW do I need to update the softdevice separately and then the app or, maybe I don't need to update the softdevice at all when updating FW ? 

3. did I understand correctly: when power up, the bootloader always runs first. Then, if there is no FW update flag, it goes to the softdevice address and then to running the app ?

4. what kind of hardware flag (I guess it's hardware, correct me if I am wrong) the bootloader checks is it a designated pin or maybe a certain register ? (if it’s a pin I am not sure how to do it because all my gpios are taken) ?

5. when bootloader needs to start (FW update flag's up), then it starts coping arriving data (in my case from uart). How can I know where it should be copied to ? and how do I copy it making sure I don't harm or attempt to write over protected flash ?

6. is there an option with the nrf52832 to work with 2 banks in case some updating did not go well ? otherwise I am running over my current app

7. does having a watchdog running in the app effect the FW update in any way ? should the bootloader with the FW update mechanism have a watchdog incase something is not working like a problem with the serial comm, and if such a problem accurse how can I make sure I keep on coping data from where I stopped, beside keeping a trek on number of bytes copied and packets ids and so ?

8. just to make sure I understand, when I want to flush a bootloader to my device I implement a bootloader project (.ses in my case working with Segger) ? if so how do I flash it to the correct location and not just like a regular app or softdevice ?

9. I read everywhere about MBR, sorry but what does MBR stands for (I could not find it in the nrf52832 data sheet) ?

10. Is there a some nrf ready to use pc app for FW updating and if so, is it an open source ?

11. do i need to reset before starting to update the FW , or can FW update accrue while app is running ?

A lot of questions I know, it's my first FW update project, hope it will not be to complicated

Best regards

Ziv

[tesc]

Hi,

You are correct that all of the examples for the open_bootloader in the examples/dfu folder of the SDK is for the nRF52840, and not for the nRF52832 or any other devices in the nRF52 series. This is most likely because the nRF52840 Dongle (the PCA10059) does not have a programmer on-board, so USB DFU is needed.

You will find examples for serial transport in the examples/dfu/secure_bootloader folder, as well as for BLE. The "secure" part of the name, reflects the ability of the bootloader to require signed upgrades. This is an optional feature, and the difference between the "secure" and "open" DFU bootloader examples lies in the configuration. You can disable (or enable) signing through the NRF_DFU_REQUIRE_SIGNED_APP_UPDATE define found in sdk_config.h. See Open Bootloader with DFU for more info on the "open" configuration.

I also recommend having a look at Getting started with Nordic's Secure DFU bootloader, a step by step guide, for getting familiar with how our DFU bootloaders work.

1. For memory layout, see Memory layout.

2. As long as the new application uses the same SoftDevice, you can update only the applicaton. Bootloader, SoftDevice and application are treated as individual components. The bootloader keeps track of SoftDevice requirements from bootloader and application, allowing only upgrades that leave the device with a combination SoftDevice/bootloader/application that is compatible.

3. Execution starts in MBR (Master Boot Record), then goes to bootloader, which decides whether to enter DFU mode or to start the application. (It enters DFU mode if requested through one of the methods for entering DFU mode, or if no valid application is found.)

4. You have several options for how to trigger DFU mode, including writing to the GPREGRET register (as showcased through the buttonless DFU example).

5. This is handled by the bootloader code. There are two types of download, which you can read about here: Dual-bank and single-bank updates. Basically, with "dual-bank" the new image is first downloaded to emtpy flash, then checked, before upgrade is completed by copying to the final location. This final step is done by the MBR, which runs at boot and is very small, uncomplicated, well tested and robust. For the bootloader to stay away from application data, you configure how many pages of application data to preserve through the DFU_APP_DATA_RESERVED define (see bottom of same documentation page as for dual-bank and single-bank updates.)

6. As mentioned in 5., "dual-bank" is one of the options and it does exactly what you suggest.

7. Bootloader can be combined with watchdog, yes. I do not know the details for that, but there are other DevZone threads covering that. If you experience any difficulties with watchdog that are not yet handled here in DevZone, then please start a new thread for that.

8. The bootloader projects are already configured to build for a particular region of flash. (Actually, the same goes for application, as it lies on top of the SoftDevice. In that regard it is very similar.) If you start off with a bootloader project from our SDK, for the device you are using, then this is already correctly configured.

9. MBR is Master Boot Record. It is the first flash page of the SoftDevice, and it does not get updated through DFU. It is part of the SoftDevice delivery, but can also be used without SoftDevice for projects that do not use SoftDevice.

10. We have development tools for running DFU from PC. For instance you can do UART DFU from nrfutil, for which you can find the source code on github: https://github.com/NordicSemiconductor/pc-nrfutil

11. While the bootloader is intended to be a standalone unit that requires booting into (without the main application of the device running), some customers have been looking into "background DFU", that is downloading the new application from the current applicaiton, instead of booting into the bootloader first. The most straight-forward would be to use the bootloader as is (that is, run DFU from within the bootloader), but if you are interested in "background DFU" then I suggest that you do a search here on DevZone for that term.

Regards,
Terje

[tesc]

Hi,

An additional note: For UART DFU on nRF52832, I recommend starting with examples/dfu/secure_bootloader/pca10040_uart or examples/dfu/secure_bootloader/pca10040_uart_debug, and modify it to use the open bootloader configurations and correct amount of DFU_APP_DATA_RESERVED for your application.

Regards,
Terje

[ziv123]

hi Tesc :) 

thanks for the detailed reply, i have a lot more to be reading now :)  and probably will have more questions after reading and starting to code

one questions though now, regarding the nrfutil, 

tesc said:

We have development tools for running DFU from PC. For instance you can do UART DFU from nrfutil, for which you can find the source code on github: https://github.com/NordicSemiconductor/pc-nrfutil

if the DFU Controller side uses the nrfutil, does it change something in the implementation on the DFU Target side, or the target still needs to implement the same bootloader and flash it via Segger debugger and so on ? 

basically i am writing the DFU Target side but still good to know if integrating the nrfutil in the DFU Controller side app saves some work for any of the sides ?

best regards

Ziv

[ziv123]

hi Tesc

as i mentioned there will be more questions for sure 

1. so i looked at the ' secure_bootloader_uart_mbr_pca10040' example in my sdk and it does not compile, the 

( #include "uECC.h" -> no such file or directory ) maybe you know why ?? 

i set the NRF_DFU_REQUIRE_SIGNED_APP_UPDATE  to  '0'  so to my understanding there should not be a need for the ley generation and the extra libraries addition ??

2. another thing is that i try to look in the main.c to understand what is happening and all i see is switching leds and could not find a check for the DFU mode trigger in the code , can you please explain what i am missing ?

3. also in my app code, do i need to add some bootload libraries to recognize the ' enter_buttonless_dfu and set it to true before restarting to get into FW update mode via mbr ? the macro ' NRF_BL_DFU_ENTER_METHOD_BUTTONLESS ' is not even found in my app code sdk_config.h file , do i add it alone or all the other definitions around it related to the booload ?

best regards

Ziv
 

[tesc]

Hi,

1. I recommend testing the BLE example first, as it covers all the steps. Please consult the Testing section of the Secure DFU Bootloader over Serial Link (UART/USB) example documentation. micro-ecc is needed for the nrf_crypto library, which is required by the bootloader. (Signing will still be required for upgrading the bootloader itself, so hence the need for the cryptography library.)

2. If you want to investigate how the bootloader works internally, you can start by looking at nrf_bootloader_init() called from main. After some initialization (depending on what triggers or enter methods are configured), you will find the checks for how the bootloader will proceed (either activating firmware from ongoing DFU, enter DFU mode, or start application.)

3. For entering the bootloader from the app, through "buttonless DFU", you must add to your app, yes. The buttonless DFU template example shows this, although it uses BLE Services for triggering the DFU. The libraries used (for the BLE services and handling of the SoftDevice write to GPREGRET registers before resetting the device, which is the way the DFU bootloader is signalled to enter DFU mode.

Regards,
Terje