Flashed PCB doesn't boot to app (stays in bootloader)

[QuentinFarizon]

I am trying to port my working application from a nrf52811/s112 to nrf52832/s132, both with SDK 16.0.0.
I'm at the end at the process, it builds fine on nrf52932, I just can't get my app to boot.
It stays in bootloader, very probably because it doesn't launch the app. It advertises as 'DfuTarg'.

I suspected a CRC issue, so I have tried setting NO_CHECKS when building the bootloader, without luck.

Here is my build process (note that I use the same process to flash the same application to nrf52811/s112) :

# Build
emBuild -config 'Release' sdk16.0.0/projet/dfu/secure_bootloader/dfu_boks/ses/secure_bootloader_ble_52832_s132.emProject
emBuild -config 'Release' sdk16.0.0/projet/app/app_boks/s132/ses/soft_my_app_52832_s132.emProject

# Settings.hex generate
nrfutil settings generate --application <my_app>_52832_s132.hex --application-version-string 2.4.2 --family NRF52 --bootloader-version 2 --bl-settings-version 2 --app-boot-validation VALIDATE_GENERATED_CRC settings.hex

# Merge hex
mergehex -m my_app_52832_s132.hex bootloader_52832_s132.hex settings.hex -o tmp.hex
mergehex -m tmp.hex s132_nrf52_7.0.1_softdevice.hex -o app_bootloader_settings_softdevice.hex

# Program
nrfjprog --eraseall
nrfjprog --program app_bootloader_settings_softdevice.hex
nrjprog --reset

Here is my bootloader placement settings, copied from the SDK example (using default flash_placement.xml from the SDK example) :

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x26000;FLASH_SIZE=0x5a000;RAM_START=0x20002220;RAM_SIZE=0xdde0"
linker_section_placements_segments="FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000;uicr_bootloader_start_address RX 0x10001014 0x4;bootloader_settings_page RX 0x0007F000 0x1000;uicr_mbr_params_page RX 0x10001018 0x4;mbr_params_page RX 0x0007E000 0x1000"

Here is my app placement settings, copied from the SDK example (using default flash_placement.xml from the SDK example) :

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x26000;FLASH_SIZE=0x5a000;RAM_START=0x20002220;RAM_SIZE=0xdde0"
linker_section_placements_segments="FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000"

Here is the generated settings.hex :

Bootloader DFU Settings:
* File: settings.hex
* Family: nRF52
* Start Address: 0x0007F000
* CRC: 0xBEC1BE15
* Settings Version: 0x00000002 (2)
* App Version: 0x00004FB2 (20402)
* Bootloader Version: 0x00000002 (2)
* Bank Layout: 0x00000000
* Current Bank: 0x00000000
* Application Size: 0x0000C1A0 (49568 bytes)
* Application CRC: 0x00061612
* Bank0 Bank Code: 0x00000001
* Softdevice Size: 0x00000000 (0 bytes)
* Boot Validation CRC: 0x52CA2133
* SD Boot Validation Type: 0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

What am I missing ? Thanks !

[Einar Thorsrud]

Hi,

You are right that the bootloader does not start the app, and a probable reason is invalid CRC. You could verify this by testing the debug bootloader with RTT logging, or by simply removing the CRC check for now. There is no configuration macro for that (not sure where you found NO_CHECKS?), but you can modifying crc_on_valid_app_required() in components\libraries\bootloader\nrf_bootloader.c to always return false. If that makes the app load as expected, then there is an issue with the CRC check for some reason. Can you tell me the result of this test?

If we assume for now that the CRC is invalid, then that can either be caused by an incorrect CRC in the bootloader settings page or that the application flash area has changed.

Typical reasons for incorrect CRC is either missing or incorrectly generated settings page, or for instance that you have generated a settings page hex that does not include the backup page, even though it is used (in MBR params page). The latter could happen if using a too old nrfutil version or using --no-backup, though I see that is not the case here).

[QuentinFarizon]

NO_CHECKS is a macro that I have in the bootloader (added in our project) that deactivates checks in crc_on_valid_app_required

So I have already tried your first suggestion and it didn't work unfortunately. I guess that rules out a failed CRC check ?


I am indeed not using --no-backup, and I'm generating settings from the same hax that I merge later in the script.

[Einar Thorsrud]

Hi,

QuentinFarizon said:

So I have already tried your first suggestion and it didn't work unfortunately. I guess that rules out a failed CRC check ?

Unless there is a mistake here, then yes (can you show how you have done it just to be sure?).

Generally, the device will enter DFU mode if dfu_enter_check() in components\libraries\bootloader\nrf_bootloader.c returns true, which is if any of the checks there are hit. I suggest you either use the debug bootloader to enable logging or use some other method to see which of these checks cause the bootloader to enter DFU mode instead of starting the application. Then fixing the issue should most likely be straight-forward.

[QuentinFarizon]

I have edited dfu_enter_check and left only : 

static bool dfu_enter_check(void)
{
    return false;
}    

And it still doesn't load the app

I will try debuggin the bootloader

[QuentinFarizon]

Not sure if I'm doing the right thing in order to debug the booloader : I have flashed the nrf52832 as previously described, with app+bootloader+settings+SD hex, and then I load the bootloader_debug project in Segger Studio and launch debug.

In nrf_bootloader_fw_activate I'm entering "No firmware to activate.", which seems to indicate there is no SD and/or app detected.

Here are the logs :

<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> nrf_dfu_settings: Backing up settings page to address 0x7E000.
001000

[Einar Thorsrud]

Hi,

From the log and knowledge that dfu_enter_check() always returns false here, it is clear that nrf_dfu_settings_backup() is called, which is close to the end of nrf_bootloader_init() in components\libraries\bootloader\nrf_bootloader.c. However, there is no log from nrf_bootloader_app_start(), which should be called next.

I do not see anything obvious, so my next idea is a bit of a shot in the dark, but it may be relevant. Have you done any other changes to the bootloader, particularly changes that could increase its size? If so, you may experience a problem that the SES bootloader project does not give you a linker error if the bootloader is up to two pages too large (overlaps MBR params page and potentially bootloader settings page). If this is the case, then you would see memory corruption and anything could happen. What is the end address of the bootloader? (One easy way to see it is to add the hex to nRF Connect Programmer and see there). If this is the problem, then moving the start address of the bootloader a bit down should fix the problem.

If that does not seem relevant, then perhaps you can add more logging to see what happens.

[QuentinFarizon]

Hello,

Bootloader is at addresse range 0x00078000 - 0x0007D631 

[QuentinFarizon]

I have checked my bootloader code against the SDK16 standard, the only difference is the build variable NO_CHECKS that stubs some application checks (and I have tried with and without)

[QuentinFarizon]

If I put a breakpoint at the end of nrf_bootloader_app_start I do get logs:
<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.
E000.
source, write not needed. Skipping.
<debug> app: Running nrf_bootloader_app_start with address: 0x00001000
<debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

Without a breakpoint, logs don't have time to be printed, and the bootloader restarts immediately, and the boot sequence appear in logs in an infinite loop.