Bootloader via DFU

[WesC]

I have a few questions about the DFU:

Is it necessary to flash everything together (Bootloader, DFU, APP) for the initial programming when testing buttonless secure DFU without bonds?

In the sections that are about the “Buttonless DFU Template Application”,  the paragraph “Bootloader settings page” page makes it clear that when bonding is enabled, the buttonless Bootloader is fully dependent on the buttonless application to create the bond with the client device. In turn, this means that testing with bonding enabled requires  initial programming with a  single “full stack”.hex file: 1) SoftDevice, 2) Bootloader with settings page that includes the app information, 3) the application that matches the info in the setting page. The paragraph “Testing Buttonless Secure DFU with bonds” works this way.

 The Bootloader settings  (in flash) are updated whenever the Application is successfully updated via DFU.
 So, I may have a the same Bootloader on more than one type of board (product1, Product2, product3, ..)
Each of these boards has its own unique application firmware.

When I need to update that bootloader on all products, can I do it with one DFU image?

If so, what stuff do I leave out of the Bootloader Setting Page of the new image?

If not, do I need a separate DFU image for every unique application?

 Are there other rules that apply in this scenario?

[Einar Thorsrud]

Hi Wes,

Is it necessary to flash everything together (Bootloader, DFU, APP) for the initial programming when testing buttonless secure DFU without bonds?

No, In this case it is enough to flash the bootloader and SoftDevice (or only MBR would be sufficient if using another transport than BLE). In this case, the MBR will start the bootloader, and the bootloader will enter DFU mode as there is no valid application present.

When I need to update that bootloader on all products, can I do it with one DFU image?

In theory yes, but in practice, no. It is probably not sensible to use the same bootloader on different products. This is because the bootloader can check if a upgrade image is suitable for itself or not, using NRF_DFU_HW_VERSION. This is set in the bootloader's sdk_config.h and is checked against the HW version that is specified when generating the .zip package using nrfutil. If those are not the same, upgrade will not be allowed. That way you ensure that only firmware suitable for the specific device can be used.

If not, do I need a separate DFU image for every unique application?

Yes. There is no support for several applications in a single DFU image (though you can have both SoftDevice, application and bootloader in a single image).

Einar

[WesC]

Thanks for the information.  I have a few more questions:

I have questions, after reading on DevZone about debugging DFU. Right now, it’s all about the bootloader and getting SES to debug the whole thing (MBR, Bootloader with settings page, SoftDevice, and my application.)

 

1. My original tests were done in the nRF52840 DK with my updated FW, and the SoftDevice – no bootloader. I learned from breakpoints, that I must have the bootloader or I’ll never get past the first DFU function call – ble_dfu_buttonless_async_svci_init().
2. I read every related question on DevZone. So here’s what I have done, and then my questions:
   1. 1. 1. I know I need a bootloader with Buttonless DFU and Without Bonds, and in sdk_config.h I set:
            1. NRF_BL_DFU_ENTER_METHOD_BUTTON to Zero (0) because I have no buttons on the (eventual) target HW.
            2. NRF_BL_DFU_ENTER_METHOD_BUTTONLESS to one (1).
            3. NRF_DFU_APP_ACCEPT_SAME_VERSION to one (1).
            4. NRF_DFU_APP_DOWNGRADE_PREVENTION to zero (0).
            5. NRF_DFU_HW_VERSION 2 same as what I have been using successfully with BUTTON.
            6. NRF_DFU_BLE_REQUIRES_BONDS to zero (0).
            7. Nothing else in my config file version was changed relative to the example secure bootloader sdk_config.h file.
         2. Is this the “debug bootloader” they talk about on the DevZone, or do I need to do other stuff to it?
         3. I didn’t find anything, but do I need to change anything in the Bootloader Settings Page?
         4. I can clear flash with nrfjprog, and use nRF Connect to program the SoftDevice and B/L (with settings page merged into it), but will SES  just erase what I just described? Do I need to manually program my buttonless DFU w/o bonds with nRF Connect too, and just tell the bootloader to debug? Or is there something else needed to pull this off? Will SES agree to debug something it didn’t flash?

[Einar Thorsrud]

Hi Wes,

WesC said:

Right now, it’s all about the bootloader and getting SES to debug the whole thing (MBR, Bootloader with settings page, SoftDevice, and my application.)

It depends on what you want to accomplish. You write "debug the whole thing (MBR, Bootloader with settings page, SoftDevice, and my application.)". Just to make it clear, you cannot easily debug the SoftDevice or MBR, as that is closed source. For the bootloader, you normally stick with debug logging. it is possible to build without optimization to do proper debugging also, but that normally not needed.

WesC said:

My original tests were done in the nRF52840 DK with my updated FW, and the SoftDevice – no bootloader. I learned from breakpoints, that I must have the bootloader or I’ll never get past the first DFU function call – ble_dfu_buttonless_async_svci_init().

Yes, that is correct. Alternatively you could comment out the call when debugging the application (as long as you don't intend to test buttonless DFU, but that is not relevant anyway without a bootloader present).

WesC said:

Is this the “debug bootloader” they talk about on the DevZone, or do I need to do other stuff to it?

The debug bootloader both has changes in sdk_config.h and in which files are added in the project (for RTT logging). You can compare the differences by looking at all example bootloader under <SDK>\examples\dfu\secure_bootloader\. For every project, there is a corresponding _debug project ending with "_debug". The difference is that it included extensive RTT logging. This increases the size, and thus decreases the start address. Except for the logging they are functionally the same as the "normal" bootloader example projects.

WesC said:

I didn’t find anything, but do I need to change anything in the Bootloader Settings Page?

That depends on what you want to do. If you make any changes to the application, you will always need to update the bootloader settings page with a updated hash of the application after building it so that the bootloader deems it valid. Alternatively, which I typically recommend when debugging an application with a bootloader present, modify the bootloader so that when testing it always assumes the application is valid. You can do this by modifying app_is_valid() in components\libraries\bootloader\nrf_bootloader.c so that it always returns true.

WesC said:

I can clear flash with nrfjprog, and use nRF Connect to program the SoftDevice and B/L (with settings page merged into it), but will SES  just erase what I just described?

Yes. When you program an application from SES is will only perform sector erase on the pages you are overwriting. So the rest will be left as is.

WesC said:

Do I need to manually program my buttonless DFU w/o bonds with nRF Connect too, and just tell the bootloader to debug?

No, SES will program for you when you start to debug.

WesC said:

Or is there something else needed to pull this off? Will SES agree to debug something it didn’t flash?

By default it will flash before debugging, and that is normally sensible. (You can debug without programming first as well by selecting Target -> Attach Debugger.)

Einar