DFU secure_bootloader example on nRF52DK doesn't advertise

[Tormod V]

I have an nRF52DK board (PCA10040 3.0.0) and try to run the pre-built secure_bootloader examples from nRF5 SDK 17.1.0 (ddde560). What can possibly go wrong?

From the folder nRF5_SDK_17.1.0_ddde560/examples/dfu/secure_dfu_test_images/ble/nrf52832 I have programmed the softdevice* softdevice_s132.hex (using nrfjprog --family nrf52 --verify --program) and then the hrs_application_s132.hex example app. After reset, this works fine, I can connect to the HRS app, so it seems that the hardware is OK. But after programming the bootloader bootloader_secure_ble_debug_without_bonds_s132.hex (and reset) there is no bootloader advertising. LED1 and LED2 are constantly lit.

Same goes, after a --recover, installing only the softdevice and bootloader (without app).

I also tried building myself the examples/dfu/secure_bootloader (make -C pca10040_s132_ble_debug/armgcc). Using the debug build, I can see that it enters DFU mode (and prints "Advertising..." on the RTT debug channel), but I don't see it advertise (using nRF Connect mobile app). Every few minutes the debugger says "external reset detected".

Can anyone confirm that these examples have been tested and work on a nRF52DK board?

Tormod

*) I also tried the components/softdevice/s132/hex/s132_nrf52_7.2.0_softdevice.hex - it differs by two bytes (0101 instead of cafe) at one place in the hex files.

Debug log:

<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.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<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 (0x20005974)
<debug> app: timer_activate (0x20005974)
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x00071000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> nrf_dfu_ble: Configuring BLE stack.
<debug> nrf_dfu_ble: Enabling the BLE stack.
<debug> nrf_dfu_ble: No advertising name found
<debug> nrf_dfu_ble: Using default advertising name
<debug> nrf_dfu_ble: Advertising...
<debug> nrf_dfu_ble: BLE DFU transport initialized.
<debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
<debug> app: Enter main loop

[Vidar Berg]

Hello,

Strange, both the LED states and debug log indicate that your device should be advertising in DFU mode. I also tried to reproduce this here by programming the same hex files you mentioned to a 52 DK, but for me it worked.

Could you try to program the 'sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_without_bonds.hex' and see if that too fails? 

E.g.

$ nrfjprog --program sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_without_bonds.hex --chiperase --verify -r 

$ nrfjprog --erasepage 0x7e000-0x8000 //Erase Bootloader settings page to force device into DFU mode on subsequent boot

$ nrfjprog -r // Check if the device advertises in DFU mode after this reset

Best regards,

Vidar

[Tormod V]

After the first command I had the buttonless app advertising, but after the erase page 0x7e000-0x80000 and reset there is nothing advertising.

[Vidar Berg]

And you are scanning for "all" devices when you test this? As you may know, the device will increment the BLE address with +1 when advertising in DFU mode and therefore make it appear as another device to the Central.

[Tormod V]

For the sake of reproducibility, after the erasepage step, the md5sum of the flash, as read back by nrfjprog -f nrf52 --readcode, is 19f0c3695d3aab4092e7021f418db7b1. After reset (and code running, which probably rewrites bootloader settings) it is 73f4ad78f2f01ab1f41ec8d0350703fa.

The board batch is 2022.10.

BTW, thanks Vidar, for looking at this so quickly!

[Vidar Berg]

No problem. Yes, the change in checksum makes sense as the bootloader will populate the settings page with default values if it sees that it is erased on startup. 

[Tormod V]

Yes, no filter applied on the mobile app.

[Tormod V]

Do you have the same checksums? In case, it suggests to me something is wrong with my board. But it seems to work fine with all the other BLE examples.