DFU / Bootloader Issues

[kentorth]

Hi there,

I'm currently using SDK 17.1.0 with the NRF52832 Development Board.  This is pretty new to me, but the examples helped me get an application going pretty quickly.  I am now at the point where I'd like to start testing with a bootloader.  I've built the micro-ecc library and generated keys.  That seems to all be working fine.  After programming the secure_bootloader/pca10040_s132_ble example, I try to use the nRF connect app and I don't see anything.  I've confirmed there is a softdevice using the Programmer v3.0.0 tool.  If I hold the IF BOOT/RESET button on power up, it pulls up the bootloader file system.  I get stuck in this state and need to drop a working binary in for it to restart and launch said binary.  However, if I program the ble_peripheral\ble_app_blinky example, I can use the nRF Blinky app and it seems to work just fine.  I just started using the Nordic board a little over a week ago so forgive me if I'm missing something.  I mainly have a couple of questions here:

1. How do I get the secure_bootloader/pca10040_s132_ble example working so I can perform DFU over BLE.

2. At minimum, I'd like to use the bootloader file system to drop my own binary image for booting.  Does this need to be signed?  I programmed the bootloader example with my own generated key, then reset with the button pressed and dropped this j-link-ob-sam3u128-v2-nordicsemi-170724.bin I found on the internet.  It seemed to boot into the application without requiring a signature.

3. If my current application doesn't require BLE, but I plan to add it down the line, should I be using the softdevice and update app later to use the BLE stack or can I just merge the softdevice with my app later and load that?

Thank you,

Kenny

[tesc]

Hi,

1. How do I get the secure_bootloader/pca10040_s132_ble example working so I can perform DFU over BLE.

Following the Testing section of the example documentation should do the trick.

Please note that holding the IF BOOT/RESET button is for programming the interface MCU (the programmer chip) on the board. It is not for programming the nRF SoC.

2. At minimum, I'd like to use the bootloader file system to drop my own binary image for booting.  Does this need to be signed?

You could set NRF_DFU_REQUIRE_SIGNED_APP_UPDATE to 0 to disable signing for the applicaiton (DFU of the bootloader itself and for the BLE stack (the SoftDevice) would then still require signing.) See also the Open Bootloader with DFU. However, signing is always a good idea, especially for over the air DFU. The

I programmed the bootloader example with my own generated key, then reset with the button pressed and dropped this j-link-ob-sam3u128-v2-nordicsemi-170724.bin I found on the internet.  It seemed to boot into the application without requiring a signature.

What you did there, was programming the on-board programmer/interface MCU, over USB.

3. If my current application doesn't require BLE, but I plan to add it down the line, should I be using the softdevice and update app later to use the BLE stack or can I just merge the softdevice with my app later and load that?

The SoftDevice, which is our BLE stack used in nRF5 SDK, is a separate binary that is not combined with the application. Each one of Bootloader, SoftDevice and application are separate binaries, and using our DFU solution they can be upgraded independently. Please note however that the bootloader cannot change in size, and you cannot change between e.g. a serial bootloader and a BLE bootloader.

Please also note that we have a new SDK, the nRF Connect SDK, which is the main recommendation for new projects - also on the nRF52 series. See our nRF Connect SDK and nRF5 SDK statement for details. For a new project, it may be better to start with the nRF Connect SDK.

Regards,
Terje

[kentorth]

Hi Terje,

I'm still following the Testing section but using the debug example.  Here is the log.  I can't seem to get past this part to the DfuTarg section.

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<warning> nrf_dfu_settings: Resetting bootloader settings since neither the settings page nor the backup are valid (CRC error).
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0007F000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007F000, len=1 pages), queue usage: 0
<debug> nrf_dfu_flash: Flash erase success: addr=0x0007F000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007F000, src=0x200096C8, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0007F000, pending 0
<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0007E000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007E000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x0007E000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007E000, src=0x20009348, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0007E000, pending 0
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<info> app: Boot validation failed. No valid app to boot.
<debug> app: DFU mode because app is not valid.
<info> nrf_bootloader_wdt: WDT is not enabled
<debug> app: in weak nrf_dfu_init_user
<debug> app: timer_stop (0x20005984)
<debug> app: timer_activate (0x20005984)
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> app: Failed to initialize transport 0, error 7
<error> app: Could not initalize DFU transport: 0x00000007
<error> app: Received an error: 0x00000003!

[tesc]

Hi,

While error code of 7 may or may not have the same root cause, an error of 9 (as you described earlier) may indicate issues with the toolchain. See SDK 17.1.0: secure bootloader runtime failure when compiled with current gcc (11.2.0). Please check that you use the toolchain that was used for testing and verifying the SDK, which according to the nRF5 SDK 17.1.0 release notes was:

The following toolchains/devices have been used for testing and verification:
 
 - ARM: MDK-ARM version 5.25   
 - GCC: GCC ARM Embedded 9.2020-q2.major
 - IAR: IAR Workbench 7.80.4
 - SES: SES 5.42a

Regards,
Terje

[kentorth]

Thank you for your prompt response.  I changed my toolchain to the version provided and I got it working.  I appreciate your help.

Thank you,

Kenny

[tesc]

Hi,

I am happy to hear that changing toolchain solved the issue. Please consider accepting the answer (should be a button on my answer from two days ago.) It will make it easier to find for others with similar questions in the future.

Regards,
Terje