Bootloader not starting application

[Elias Löwe]

Hello

I have two similar (as their producer says) boards. Both nRF52832. The main difference is in modems used for external data transmission.

SDK 15.0.0

SD 132

I have one firmware for this project. HW dependent code is separated by C macroses. Rest of firmware is the same. I have shell script that generate settings, merge it with booloader, than merge result with softdevice and application and flash it using `nrfjprog`.

One board works fine. Second board always in DfuTarg mode.

I even tried to flash working board with firmware for other one and realized that application is loaded. Which never happens in case of second board.

What could be the reason of such behaviour? If it is difference in HW, then what kind of?

[Edvin]

Hello,

I assume that this is related to your other ticket?

What happens if you try to perform a DFU with the same application that you generated the bootloader settings with? (remember that you have to create a new DFU packet with application-version higher than the current application version in the bootloader settings).

BR,

Edvin

[Elias Löwe]

For me it looks like two different issues.

If I prepare another zip with higher version (previous was 0.1.1) using command

```nrfutil pkg generate --application Output/Release_Board2/Exe/my_app.hex --hw-version 52 --sd-req 0xA8 --application-version-string 0.1.2 --key-file private.pem my_app-Board2-0.1.2.zip```

Then flash it using BLE, update goes fine, nRFConnect on iOS says "Complete" but device advertise itself as DfuTarg again.

[Edvin]

Hello,

You have flashed the same bootloader to both devices, right?

Can you please try to use the debug bootloader on this chip? Then enable logging in that bootloader to check what is going on. 

If the transmission starts, it means that the key-file, the application version, the hw version and sd req are all ok. The only thing I can thing of is that the crc calculation that is done after the application is received is not correct. Did you change anything in the bootloader, (other than the WDT from your other ticket)?

Do you know what the differences are between your two boards?

Best regards,

Edvin

[Elias Löwe]

The only change in bootloader I have is my generated by nrfutil public key.

If I erase chip, run run secure_bootloader debug version and flash the device with FW over BLE, I get this in log:

```

*** FW TRANSFER LOG ***

<debug> nrf_dfu_req_handler: All flash operations have completed. DFU completed.
<debug> app: Shutting down transports (found: 1)
<debug> nrf_dfu_ble: Shutting down BLE transport.
<debug> nrf_dfu_ble: Disconnecting.
<debug> nrf_dfu_ble: BLE transport shut down.
<debug> app: Resetting bootloader.
<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> app: Enter nrf_bootloader_fw_activate
<debug> app: Valid App
<debug> app: Enter nrf_dfu_app_continue
<debug> app: No copy needed src_addr: 0x26000, dst_addr: 0x26000
<debug> app: Setting app as valid
<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=0x20008F84, len=440 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0007F000, pending 0
<debug> app: Resetting bootloader.
<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> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<debug> app: Enter nrf_dfu_app_is_valid
<debug> app: Return true. App was valid
<debug> app: DFU mode requested via button.
<info> nrf_bootloader_wdt: WDT is not enabled
<debug> app: in weak nrf_dfu_init_user
<info> app_timer: RTC: initialized.
<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: 0x00072000
<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

```

[Edvin]

Hello,

It seems that the app transfer is perfectly fine. The issue is that when it is done, and restarts, it checks the DFU button which is "pushed". I say "pushed" because on your board, it is not certain that it is a button there at all.

You see the line

<debug> app: DFU mode requested via button.

This comes from line 271 in nrf_bootloader.c, where it checks:

if (NRF_BL_DFU_ENTER_METHOD_BUTTON && (nrf_gpio_pin_read(NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN) == 0 ))

I assume that this pin is grounded on the board that is not working. By default, NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN is 16, so check your pin P0.16.

So either, you need to change the pin that you want to use as your bootloader pin. (If held down on reset, it goes to DFU), or you have to disable this feature by changing NRF_BL_DFU_ENTER_METHOD_BUTTON to 0 (It is set to 1 by default in sdk_config.h).

Best regards,

Edvin

[Elias Löwe]

Perfect! Thank you very much, Edvin!

This solves the issue. PIN 16 is realy used differenntly on those boards.