Device enters and stays in bootloader mode on start

[Tibor Kakonyi]

Hi Team,

I am prototyping a product that includes DFU OTA using nRF52832.
To get familiar with the topic, I am experimenting with the buttonless DFU example.

It is working fine with the pre-compiled test-image sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_with_bonds.hex.
However, I would like to make changes to the example app and create my own DFU-ready firmware. When I do that, after downloading the image to the device, it automatically goes to bootloader mode, and I cannot make it run the firmware app itself.
I generated my key pair and replaced the default one, installed microECC, compiled hex files for the bootloader and for the app. 
Then generated the boot loader settings page:
nrfutil settings generate --family NRF52 --application ble_app_buttonless_dfu_pca10040_s132.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 bl_settings_page.hex
Output:
Bootloader DFU Settings:
* File: bl_settings_page.hex
* Family: nRF52
* Start Address: 0x0007F000
* CRC: 0xA3601442
* Settings Version: 0x00000001 (1)
* App Version: 0x00000001 (1)
* Bootloader Version: 0x00000001 (1)
* Bank Layout: 0x00000000
* Current Bank: 0x00000000
* Application Size: 0x0000CF68 (53096 bytes)
* Application CRC: 0x97473D39
* Bank0 Bank Code: 0x00000001
* Softdevice Size: 0x00000000 (0 bytes)
* Boot Validation CRC: 0x00000000
* SD Boot Validation Type: 0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

The merged all the hex files into the final image: 
mergehex --merge s132_nrf52_7.2.0_softdevice.hex ble_app_buttonless_dfu_pca10040_s132 secure_bootloader_ble_s132_pca10040.hex --output temp_merg.hex
mergehex --merge s132_nrf52_7.2.0_softdevice.hex ble_app_buttonless_dfu_pca10040_s132.hex secure_bootloader_ble_s132_pca10040.hex --output temp_merg.hex

Another strange thing that I think is related this problem: after downloading this image to the device, nRF Programmer shows that there is no SoftDevice on it. See the screenshot attached - the blue area is missing on the figure on the right side.

Can you please help me solve this issue(s)?

Thanks in advance,
Tibor

[Einar Thorsrud]

Hi Tibor,

Do you include the settings page in your merged hex file? I do not see it listed where you copy--pasted the mergehex commands. If not, then it would explain what you are seeing.

If the above is not the problem, then perhaps you are seeing a known issue with the latest mergehex (10.12.1) where it can create corrupt images. Can you revert to an older version and see if the issue persist? Alternatively add all separate hex files to nRF Connect Programmer instead of using mergehex?

If the issue persists then it would be good if you can test with the debug bootloader project (suffixed _debug) which includes RTT logging and upload the log here. In most cases the RTT log gives a good indication of where to look.

Einar

[Tibor Kakonyi]

Hi Einar,

First, I simply tried adding separate hex files to nRF Connect Programmer instead of using mergehex, but the problem still existed.

Then, as you proposed, I changed to the debug bootloader project to get more info - and for some strange reason, the process is working correctly with it. I don't know what's happening, everything else (firmware app, bootloader settings page, SoftDevice) is the same, do you have any idea?

However, the non-working bootloader version has some basic RTT logging too, let me copy-paste its output here, might be useful:
00> <info> app: Inside main
00> 
00> <info> nrf_dfu_settings: Old settings page detected. Upgrading info.
00> 
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00> 
00> <info> app: No firmware to activate.
00> 
00> <warning> app: Boot validation failed. App is invalid.
00> 
00> <info> nrf_bootloader_wdt: WDT is not enabled
00> 
00> <info> app: Entering DFU mode.

Thank you,
Tibor

[Einar Thorsrud]

Hi Tibor,

It is odd that you see a difference between the debug and normal bootloader. However, this printout makes me spot a detail I did not see before. You specify --bl-settings-version 1, but the current version is 2 and based on the SoftDevice version I assume you are using a recent SDK version. Can you specify --bl-settings-version 2 instead when you generate the setting page?

Einar

[Tibor Kakonyi]

Thank you very much, Einar! Using --bl-settings-version 2 solved the problem :)