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]

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

[QuentinFarizon]

OK I am further, I've successfully flashed blinky to my DK, with your provided bootloader and with mine.
I checked again that there are no modifications done to my bootloader compared to SDK 16.

I then tried to flash blinky to my custom PCB, and it doesn't blink (the LEDS on my PCB do have the same pin numbers than the pca10040)

[QuentinFarizon]

I can successfully connect with RTTViewer, but there is no output even though I'm using the same bootloader that gives me output on the DK

[Einar Thorsrud]

I see. So with the exact same merged hex file that works on the nRF52832 DK your custom HW stays in the bootloader. According to the log in an eternal loop where it seems to start the app, but then there must be a reset for some reason, as the bootloader starts again right after. Is that a summary of the current state?

Regarding missing RTT output that can be explained if you have had some other firmware before and did not power-cycle and that results in two RTT buffers at different locations, and the RTT viewer finding the wrong one first. But if you still don't get RTT logs after power-cycling that is not the case. This leads me to another question. Do you know that the board works at all? What if you test with the blank blinky example (no SoftDevice) without any bootloader? Specifically, first erase the board using "nrfjprog -e" and then flash blinky_pca10040.hex from examples/peripheral/blinky/hex/ ?

A typical reason for applications that work on a DK to fail on a custom board is a custom board without a 32 kHz LF clock. This is not relevant for the blinky example though, as it does not use any resources except for a few GPIO output pins. This leaves me without a lot of ideas. Can you upload schematics of your custom board? I am not looking for anything particular, but perhaps it would show something interesting.

[QuentinFarizon]

Ok I didn't know you could flash the app alone !
Working from this, I managed to flash blinky on my board, and then my app, and then app+bootloader, by fixing the flash/ram placement (not sure what I changed).

I've managed to understand the reboot, due to crashes in my app during memory access, I'll open a new ticket for that if needed.