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 !

[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