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

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

Chibi — Wed, 19 Feb 2020 09:59:42 GMT

Perfect. Thanks.

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

Hung Bui — Wed, 19 Feb 2020 09:12:00 GMT

Hi Chibi,

I'm glad that you found a workaround. Please just leave this case like this. You can come back or open a new case if there is a new question.

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

Chibi — Tue, 18 Feb 2020 16:12:58 GMT

Hi Hung Bui,

Just a short follow-up to say that I could not get the NRF log output to be displayed (even after erasing the whole chip) in the JLink RTT Viewer / Client. However, I did manage to get the log output redirected to the USB CDC virtual COM port instead and that works perfectly.

Is there something I need to do to mark this case as to be closed / answered?

Thanks again for all your help and assistance.

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

Chibi — Mon, 17 Feb 2020 10:27:12 GMT

Sorry for the late reply.

I checked the sdk_config.h file and NRF_LOG_ENABLED was already set to 1. The NRF_LOG_BACKEND_RTT_ENABLED setting was also set to 1.

I didn't erase the whole chip before so I'll give that a go and report back on my findings.

Thanks again.

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

Hung Bui — Thu, 13 Feb 2020 14:32:13 GMT

Please check sdk_config.h file to see if NRF_LOG_ENABLED = 1 ?

Also make sure you erase the chip before testing with the debug bootloader as the address of the debug bootloader is different from the normal one. The chip need to be erased if you want to change bootloader address.

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

Chibi — Thu, 13 Feb 2020 14:09:57 GMT

Thanks for your time and clear explanations. It has been very helpful and I'm starting to understand what is going on.

One final question, if I may:

I tried to use the _debug version of the secure DFU bootloader but I didn't see any output on the JLink RTT Viewer or the JLink RTT client. Any ideas how to get the logging to appear?

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

Hung Bui — Thu, 13 Feb 2020 12:25:55 GMT

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.

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

Chibi — Thu, 13 Feb 2020 10:50:33 GMT

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?

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

Hung Bui — Thu, 13 Feb 2020 09:40:02 GMT

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

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

Chibi — Thu, 13 Feb 2020 08:31:39 GMT

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

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

Chibi — Wed, 12 Feb 2020 09:57:52 GMT

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:

The bootloader starts at flash address 0xF4000, is that correct for the nRF52840?
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.

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

Hung Bui — Tue, 11 Feb 2020 16:54:38 GMT

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

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

Chibi — Tue, 11 Feb 2020 15:35:27 GMT

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.

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

Hung Bui — Tue, 11 Feb 2020 15:16:50 GMT

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.