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.

[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.

[Einar Thorsrud]

From this lok it looks like the app is started. The last two log printouts are from nrf_bootloader_app_start() in components\libraries\bootloader\nrf_bootloader_app_start.c and I would not expect to see more logs from the bootloader after this point even when things are working. Could it be that for some reason a reset happens early in the app? What happens if you use a dummy app which does nothing other then entering a loop doing nothing in main()? Do you still get this reset loop?

Are you able to run this on a DK? If so, can you upload your bootloader project and app (could be just a minimal app you use to reproduce this issue) so that I can test on my side?

[QuentinFarizon]

I will check what happens on the app side, but it is the same code that works in production on nrf52811.

I have watchdog enabled, can this be a cause due to differences between 811/832 ?

What minimal app from the examples do you suggest ? I will try on my DK

[Einar Thorsrud]

Hi,

QuentinFarizon said:

I will check what happens on the app side, but it is the same code that works in production on nrf52811.

I see. The bootloader should also work on both, so the issue can be anywhere. But based on the logs, I suspect either the app, or potentially watchdog now that you mention it.

QuentinFarizon said:

I have watchdog enabled, can this be a cause due to differences between 811/832 ?

It should not be, but this is worth checking. First off all, do you see the same behaviour without a watchdog? If not, then we need to look closer in that direction. And if you do, what reload value (timeout) have you configured?

QuentinFarizon said:

What minimal app from the examples do you suggest ? I will try on my DK

It does not matter, really. Can be anything very simple. Perhaps the blinky example, either as is, or with everything except an empty loop left (so it cannot fail).

[QuentinFarizon]

Is this expected to have same or different RAM_START and RAM_SIZE  between the bootloader and the application ? 

In the examples I find :

examples/iot/bootloader/pca10040/s132/ses/iot_secure_dfu_bootloader_secure_dfu_s132_pca10040.emProject (bootloader)
RAM_START=0x20004000;RAM_SIZE=0xbad0

examples/peripheral/blinky/pca10040/s132/ses/blinky_pca10040_s132.emProject (application)
RAM_START=0x20005968;RAM_SIZE=0xa698

Should I have different ram parameters between bootloader and app ? Should I use these values ?

[Einar Thorsrud]

Hi,

The RAM start address depends on the RAM required for the SoftDevice, so that will often be different from the application and bootloader. You can see here how to find the correct RAM start address. An important point here is that there is no problem setting the start address higher than needed (and thus size lower), as long as the app still have enough. The problem is if the app/BL RAM and SoftDevice RAM overlaps. But in that case you will get an error when initializing the SoftDevice if you are using the SoftDevice handler library (like all example application in the SDK).

By the way, I am surprised that you refer to a IoT bootloader project. Is that a coincidence (random pick to get an example) or is that what you are using?

Did you check if you still get this problem if testing without a watchdog? If not, du you have a reason to suspect that RAM is a problem?

[QuentinFarizon]

> I am surprised that you refer to a IoT bootloader project. Is that a coincidence
Random pick, sorry.
I put back the same RAM_START for bootloader and app

I tried deactivating the watchdog, no change ... I'm out of ideas 

[Einar Thorsrud]

I see. Did you test with the blinky example as I suggested? Just to test a example that virtually cannot fail (as from the bootloader logs it looks like the application is started)?

[QuentinFarizon]

I'm still trying to test that, but I'm lost on how to debug the bootloader in that case.

Here is what I do 
1. I'm merging bootloader+app+SD+settings, erase, program, reset
2. Open the bootloader project, click debug
=> When I debug s_dfu_settings, there is no app version, no bank0 abnk code, etc ...

What am I missing ? 
Thanks !
Best regdards

[Einar Thorsrud]

Hi,

The bootloader project has optimizations enabled to keep size down so you cannot debug. But it should not be needed. Have you done any modifications in your bootloader compared to the SDK 16 bootloader? if yes, can you share your bootloader or a diff?

Just for reference Here I upload a few files. The debug bootloader project for the nRF52 DK from SDK 16 (only modified with another public key), the Blinky hex merged with the S132 and a settings hex generated in exact same way as you here. So this is essentially the same as you do. With that, the bootloader start the application as expected and the DK starts blinking. I expect you see the same if you test this on your HW? If not we need to look into that as well.

8875.merged.hex

4456.settings.hex

8688.secure_bootloader_ble_s132_pca10040_debug.hex

blinky_pca10040_s132.hex