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

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

QuentinFarizon — Wed, 27 Jan 2021 15:56:42 GMT

Just for your information, I was bit by this : https://devzone.nordicsemi.com/f/nordic-q-a/29041/how-to-enable-p0-09-and-p0-10-as-gpio-pins-on-the-nrf52-instead-of-nfc-pins which messed my SPI pin

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

Einar Thorsrud — Wed, 27 Jan 2021 14:41:09 GMT

That makes sense, which is always good 🙂

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

QuentinFarizon — Wed, 27 Jan 2021 14:33:18 GMT

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.

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

Einar Thorsrud — Tue, 26 Jan 2021 18:15:08 GMT

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.

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

QuentinFarizon — Tue, 26 Jan 2021 16:09:50 GMT

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

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

QuentinFarizon — Tue, 26 Jan 2021 16:07:12 GMT

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)

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

Einar Thorsrud — Tue, 26 Jan 2021 14:30:05 GMT

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.

devzone.nordicsemi.com/.../8875.merged.hex

devzone.nordicsemi.com/.../4456.settings.hex

devzone.nordicsemi.com/.../8688.secure_5F00_bootloader_5F00_ble_5F00_s132_5F00_pca10040_5F00_debug.hex

devzone.nordicsemi.com/.../blinky_5F00_pca10040_5F00_s132.hex

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

QuentinFarizon — Mon, 25 Jan 2021 18:03:09 GMT

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

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

Einar Thorsrud — Mon, 25 Jan 2021 14:20:31 GMT

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)?

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

QuentinFarizon — Mon, 25 Jan 2021 13:53:27 GMT

> 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

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

Einar Thorsrud — Mon, 25 Jan 2021 12:57:07 GMT

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?

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

QuentinFarizon — Fri, 22 Jan 2021 14:48:05 GMT

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 ?

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

Einar Thorsrud — Fri, 22 Jan 2021 11:38:39 GMT

Hi,

[quote user="QuentinFarizon"]I will check what happens on the app side, but it is the same code that works in production on nrf52811.[/quote]

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.

[quote user="QuentinFarizon"]I have watchdog enabled, can this be a cause due to differences between 811/832 ?[/quote]

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?

[quote user="QuentinFarizon"]What minimal app from the examples do you suggest ? I will try on my DK[/quote]

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

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

QuentinFarizon — Fri, 22 Jan 2021 11:32:51 GMT

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

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

Einar Thorsrud — Fri, 22 Jan 2021 11:28:21 GMT

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?

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

QuentinFarizon — Thu, 21 Jan 2021 14:53:48 GMT

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.

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

QuentinFarizon — Thu, 21 Jan 2021 14:42:21 GMT

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)

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

QuentinFarizon — Thu, 21 Jan 2021 14:33:21 GMT

Hello,

Bootloader is at addresse range 0x00078000 - 0x0007D631

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

Einar Thorsrud — Mon, 11 Jan 2021 08:00:39 GMT

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.

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

QuentinFarizon — Fri, 08 Jan 2021 14:37:59 GMT

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

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

QuentinFarizon — Fri, 08 Jan 2021 14:16:55 GMT

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

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

Einar Thorsrud — Fri, 08 Jan 2021 11:08:05 GMT

Hi,

[quote user="QuentinFarizon"]So I have already tried your first suggestion and it didn't work unfortunately. I guess that rules out a failed CRC check ?[/quote]

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.

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

QuentinFarizon — Fri, 08 Jan 2021 09:22:56 GMT

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.

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

Einar Thorsrud — Fri, 08 Jan 2021 08:47:33 GMT

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