Blinky Application Not Executing in IAR when Secure DFU Bootloader is Present

[Chibi]

Hi,

I am using an nrf52840 MCU, Nordic SDK 16.0.0 and IAR Workbench for ARM v8.40.1.

The MCU has the following configuration:

- MBR installed

- DFU secure bootloader (USB only) installed and functional

- Bootloader settings installed

For the main application, I'm trying to use the example blinky application. The main application is downloaded via the Segger interface using IAR.

Using the above setup, my issue is that the blinky application does not execute at all - even after a power cycle.

If I erase the secure bootloader and its settings, leaving only the MBR, the blinky application then executes correctly, e.g.:

1. Erase the entire flash

nrfjprog.exe --family NRF52 --eraseall

Output:

Erasing user available code and UICR flash areas.
Applying system reset.

2. Program the MBR

nrfjprog --reset --program mbr.hex  --family NRF52 --sectoranduicrerase

Output:

Parsing hex file.
Erasing page at address 0x0.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

3. Program Blinky App

nrfjprog --reset --program blinky_pca10056_mbr.hex --family NRF52 --sectoranduicrerase

Output:

Parsing hex file.
Erasing page at address 0x1000.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

The ROM settings for the blinky example is: 0x1000 - 0xfffff

The RAM settings for the blinky example is: 0x20000008 - 0x2003ffff

Any ideas what I'm missing?

Thanks to all in advance.

[Hung Bui]

Hi Chibi, 

Could you please also post how you generate the bootloader setting ? 

If the bootloader setting is not generated and flashed properly, the bootloader won't jump to the application. 

When you said you programmed the blinky example and it didn't work when the bootloader is flashed, how did you program the blinky example ? 
Did you do DFU to flash the blinky example or you flash it directly ? 

You can enable logging inside the bootloader to have more information. 

[Chibi]

Hi Hung Bui,

Bootloader Settings Generation:

nrfutil.exe settings generate --family NRF52 --application blinky_pca10056_mbr.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex

Output:

Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.

Generated Bootloader DFU settings .hex file and stored it in: settings.hex

Bootloader DFU Settings:
* File:                     settings.hex
* Family:                   nRF52
* Start Address:            0x0007F000
* CRC:                      0x836566AC
* Settings Version:         0x00000001 (1)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x00000618 (1560 bytes)
* Application CRC:          0x055A1126
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x00000000
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

Program the Bootloader Settings:

nrfjprog --program settings.hex -f NRF52 -r

Output:

Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

To program the blinky example, I initially tried just IAR but I've also tried via the command line, as per my original post.

I'm not using DFU quite yet - I just wanted to get a basic setup working first before creating the encrypted DFU packages.

I'll try to enable the logging to see if I can extract more information.

[Hung Bui]

From SDK v15.3 the bootloader setting version should be 2. Please see here: https://infocenter.nordicsemi.com/topic/ug_nrfutil/UG/nrfutil/nrfutil_settings_generate_display.html?cp=8_5_6

If the issue persists please send us your hex files

[Chibi]

Thanks Hung Bui - it looks like my bootloader settings is incorrect.

Two of my settings were wrong:

- bl-settings-version should be 2 (for all SDKs >= 15.3.0)

- family should be NRF52840

I did eventually track it down to the following DFU secure bootloader code (in the red box) that was failing:

Note that I had to temporarily comment out the "static" keyword so I can debug it within IAR.

Bootloader Settings Generation:

nrfutil.exe settings generate --family NRF52840 --application blinky_pca10056_mbr.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex

Output:

Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.

Generated Bootloader DFU settings .hex file and stored it in: settings.hex

Bootloader DFU Settings:
* File:                     settings.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x7B2ABE87
* Settings Version:         0x00000002 (2)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x00000618 (1560 bytes)
* Application CRC:          0x055A1126
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x74D072B7
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

I tried programming the new bootloader settings file:

nrfjprog --program settings.hex -f NRF52 -r

But that failed with:

Parsing hex file.
Reading flash area to program to guarantee it is erased.
ERROR: The area to write is not erased.

To get the programming of the bootloader settings to complete successfully, I had to do the following:

1. Erase the entire flash

nrfjprog.exe --family NRF52 --eraseall

Output:

Erasing user available code and UICR flash areas.
Applying system reset.

2.Program the MBR

nrfjprog --reset --program mbr.hex  --family NRF52 --sectoranduicrerase

Output:

Parsing hex file.
Erasing page at address 0x0.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

3.Program the Bootloader Settings

nrfjprog --program settings.hex -f NRF52 -r

Output:

Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

4. Program the Bootloader

nrfjprog --reset --program secure_bootloader_usb_mbr_pca10056.hex --family NRF52 --sectoranduicrerase

Output:

Parsing hex file.
Erasing page at address 0xF4000.
Erasing page at address 0xF5000.
Erasing page at address 0xF6000.
Erasing page at address 0xF7000.
Erasing page at address 0xF8000.
Erasing page at address 0xF9000.
Erasing page at address 0xFA000.
Erasing page at address 0xFB000.
Erasing page at address 0xFC000.
Erasing page at address 0xFD000.
Erasing UICR flash area.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

5. Program Blinky App

nrfjprog --reset --program blinky_pca10056_mbr.hex --family NRF52 --sectoranduicrerase

Output:

Parsing hex file.
Erasing page at address 0x1000.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

The above steps worked for me - the Blinky app is now up and running alongside the secure DFU bootloader! 

I have some further questions:

1. The bootloader starts at flash address 0xF4000, is that correct for the nRF52840?
2. It looks like the bootloader settings file must be regenerated and reprogrammed each and every time when the main application is modified / updated (e.g. in this case, Blinky), is that assumption correct?

Your help is much appreciated.

[Chibi]

Hi Hung Bui, are you still around? When you have time, could you please respond to my two additional queries above? Thanks.

[Hung Bui]

Hi Chibi, 

Sorry, I was not at the office yesterday. Regarding your questions: 

- 0xF4000 is correct address. You can find the start address in linker setting. 

- The main purpose of the bootloader setting is to tell the bootloader that the chip has a valid application (so that the bootloader wouldn't stay in DFU mode but start the application) This requires the CRC verification and this explain why when you change the application the bootloader wouldn't enter the application. I have some explanation in this blog: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader#h61sjziauupw1j397q9s9ldr01q4j6d5

- For development, that you don't need to update bootloader setting each time you edit your app,  you can modify the app_is_valid() to always return true. Make sure to change it back after you done with development. 

- If you want to debug the bootloader, use the _debug version , make sure the optimization level is 0 

[Chibi]

HI Hung Bui,

Welcome back and thanks very much for your responses.

Concerning the bootloader start address, I see the following from the SDK 16.0.0 online reference:

The online documentation suggests the start of the bootloader is located at 0xF8000?

As for the bootloader settings, your explanation is pretty clear. However, we might end up just regenerating it every time the main application firmware is updated.

If I perform a DFU over the USB virtual COM port interface, does that mean the application firmware will need to be merged with the bootloader settings first, before creating the DFU package?

[Hung Bui]

The documentation was an example of the BLE bootloader, not the USBD bootloader. The USB library causes the size to be increased quite a lot hence the start address moved to 0xF4000

The bootloader setting as I explained is only to manually "tell" the bootloader that there already a valid application and it doesn't need to enter DFU mode. If the application is programmed to the chip via the DFU process (via the bootloader) the bootloader will write to bootloader setting automatically, you don't need to flash the bootloader setting.