Bootloader via DFU

RE: Bootloader via DFU

Einar Thorsrud — Fri, 24 Sep 2021 11:56:12 GMT

Hi Wes,

[quote user="WesC"]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.)[/quote]

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.

[quote user="WesC"]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().[/quote]

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

[quote user="WesC"]Is this the “debug bootloader” they talk about on the DevZone, or do I need to do other stuff to it?[/quote]

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.

[quote user="WesC"]I didn’t find anything, but do I need to change anything in the Bootloader Settings Page?[/quote]

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.

[quote user="WesC"]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?[/quote]

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.

[quote user="WesC"]Do I need to manually program my buttonless DFU w/o bonds with nRF Connect too, and just tell the bootloader to debug?[/quote]

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

[quote user="WesC"]Or is there something else needed to pull this off? Will SES agree to debug something it didn’t flash?[/quote]

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

RE: Bootloader via DFU

WesC — Thu, 23 Sep 2021 18:58:40 GMT

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

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().
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?

RE: Bootloader via DFU

Einar Thorsrud — Tue, 14 Sep 2021 13:36:10 GMT

Hi Wes,

[quote user=""]Is it necessary to flash everything together (Bootloader, DFU, APP) for the initial programming when testing buttonless secure DFU without bonds?[/quote]

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.

[quote user=""]When I need to update that bootloader on all products, can I do it with one DFU image?[/quote]

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.

[quote user=""]If not, do I need a separate DFU image for every unique application?[/quote]

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