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]

Tormod V said:

But it seems to work fine with all the other BLE examples

Have you tried to build the bootloader project yourself? Or have you only been testing with the pre-compiled hex files so far?

[Tormod V]

$ nrfjprog -f nrf52 --readregs
          R0: 0x0000025278
          R1: 0x002000B1B0
          R2: 0x0000000000
          R3: 0x0000000011
          R4: 0x00200000B8
          R5: 0x0000000000
          R6: 0x00E000E000
          R7: 0x0000000000
          R8: 0x0000000000
          R9: 0x0000000000
         R10: 0x0000000000
         R11: 0x0000000000
         R12: 0x002000B164
          SP: 0x002000B1B0
          LR: 0x0000016299
          PC: 0x0000025278
        xPSR: 0x0061000000
         MSP: 0x002000B1B0
         PSP: 0x0000000000
         RAZ: 0x0000000000
        CFBP: 0x0000000000
        APSR: 0x0060000000
        EPSR: 0x0001000000
        IPSR: 0x0000000000

[Tormod V]

Yes, the debug log in the original post was from the self-built debug variant.

[Tormod V]

As you can see it is a plain board with nothing connected.

EDIT: The computer was connected :) But I also tried without computer, running off the 3V battery.

[Vidar Berg]

Yes, it does not make much sense. The logs, register values, and LED states all indicate that the board should be advertising.

I got the exact same register values here as well when my board is advertising in DFU mode. The PC shows that the program is in the wait for event loop inside the Softdevice (entered through sd_app_evt_wait()) which is expected when the device is advertising waiting for a DFU controller to connect.

To make sure I am not overlooking anything here, could you let me know what app/device you use to scan for your device? 

[Tormod V]

The app is nRF Connect 4.26.0 on a Samsung Galaxy 5 with Android 12. I've used this successfully with a lot of BLE devices, including a nRF51 DFU bootloader, which shows up as "DfuTarg" (just tried again now).

[Tormod V]

I'll be d*mned, I think you are onto something. Instead scanning with hcitool lescan on my laptop I see there is a "DfuTest" that I don't see on the phone. And on another phone (with 4.24.1) it shows up... There is a dozen of devices on both phones, just "DfuTest" missing on the one I had been using all this time.

EDIT: I downgraded to 4.24.1 on the "bad" phone, but it didn't help. It seems as if it has a built-in "DfuTest" filter... Why should it see "HRS" and "buttonless" with the same softdevice, but not "DfuTest"?

[Vidar Berg]

I do not recall having seen anything like this before. There is no default built-in filter in the nRF connect app, at least not that I am aware of. Only place where filters are configured in the app is here:

[Tormod V]

Yes, it is weird. I deleted the app and reinstalled the latest version again, to no avail. I know about the filter settings, I have been using them and pay attention to them. I sometimes use the "Exclude" options but they were also off in this case (IIUC they won't filter nRF bootloaders anyway). I also compared Settings between the two phones.

[Vidar Berg]

I agree, it is weird. Could you try another third-party BLE app to see if it results in the same problem? It will help us narrow down the problem at least. 

Here is an app I found which may work for this purpose:

https://play.google.com/store/apps/details?id=uk.co.alt236.btlescan&hl=en&gl=US&pli=1