Secure Bootloader does not start application

[Lex]

Hello community!

I have curious problems with the bootloading process in SDK 17.0.2. What I am trying to do is the following:

1. Create a bootloader settings page with nrfutil 6.1.0:

nrfutil settings generate --family NRF52840 --application APP.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 BLS.hex

2. Merge the secure bootloader (UART DFU version), the settings page, the application (ble_app_blinky) and the softdevice (s140 version 7.2.0) together:

mergehex --merge BL.hex BLS.hex SD.hex --output BL_BLS_SD.hex
mergehex --merge BL_BLS_SD.hex APP.hex --output Production.hex

3. Erase flash and program the nrf52840 with the merged hex file:

nrfjprog --family nrf52 --recover
nrfjprog --reset --program Production.hex

4. Restart the board.

My expectation: After the restart, the application should start running.

What happens:  The bootloader gets stuck in DFU mode.

At the same time, I also check the memory layout with the desktop application nRF Connect - Programmer. It shows the following weird image:

 I read the following values when I hover over the different sections (from bottom to top):

1. Region name: MBR or Application / Address range: 0x00000000 - 0x00000AFF / Size: 2816 bytes

2. Region name: Application / Address range: 0x00000FF8 - 0x0002663F / Size: 153160 bytes

3. Region name: Application / Address range: 0x00027000 - 0x0002CB27 / Size: 23336 bytes

4. Region name: Bootloader / Address range: 0x000F8000 - 0x000FD83F / Size: 22592 bytes

5. Region name: MBR Parameters / Address range: 0x000FE000 - 0x000FE32F / Size: 816 bytes

6. Address range: 0x000FF000 - 0x000FF32F / Size: 816 bytes

Out of curiosity, I decide to test the DFU process to see what happens. I proceed to send the DFU zip file via UART:

nrfutil pkg generate --hw-version 52 --sd-req 0x0100 --application-version 0 --application APP.hex --key-file private_key.pem app_dfu_package.zip 
nrfutil dfu serial -pkg app_dfu_package.zip -p COM5 -b 115200

It works fine and the application starts running. But, when I check the memory layout again, this is the ugliness that greets me (bottom to top):

1. Region name: MBR or Application / Address range: 0x00000000 - 0x00000AFF / Size: 2816 bytes

2. Region name: Application / Address range: 0x00000FF8 - 0x0002663F / Size: 153160 bytes

3. Region name: Application / Address range: 0x00027000 - 0x0002CB1F / Size: 23328 bytes

4. Region name: Application / Address range: 0x0002D000 - 0x00032B1F / Size: 23328 bytes

5. Region name: Bootloader / Address range: 0x000F8000 - 0x000FD83F / Size: 22592 bytes

6. Region name: MBR Parameters / Address range: 0x000FE000 - 0x000FE05B / Size: 92 bytes

7. Address range: 0x000FE25C - 0x000FE32F / Size: 212 bytes

8. Address range: 0x000FF000 - 0x000FF05B / Size: 92 bytes

9. Address range: 0x000FF25C - 0x000FF32F / Size: 212 bytes

I have to add to the story that I have successfully implemented a similar bootloading process before, but that time I was using SDK 15.0.0 (now 17.0.2), secure bootloader with BLE DFU (now UART DFU), and probably an older version of the nRF Command Line Tools.

Please help me find what the problem is!

[Edvin]

Hello,

It looks like your setup should work. Perhaps you have a too old version of nrfutil? Since it was working in SDK15.0.0. Does your nrfutil output this warning when you generate the settings?

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.

If not, try to update to nrfutil v6.1.0. You can find the executable here: https://github.com/NordicSemiconductor/pc-nrfutil/releases

or you can use python pip:

pip install nrfutil

Let me know if upgrading nrfutil doesn't work, and we will look deeper into this.

Best regards,

Edvin

[Lex]

Hi, thanks for your fast reply! My wording might have been confusing, but if you look at the second sentence in my post, it says: 

Lex said:

1. Create a bootloader settings page with nrfutil 6.1.0:

I mean, it was a previously developed product that I used SDK 15 and an older version of nrfutil. And, in that product, everything worked just fine.

Anyway, I have just found another clue! I get the following message in the desktop nRF Connect v3.6.1 - Programmer:

 

I get this message when I try to program the merged Production.hex file by clicking the menu option "Add HEX file", then choosing Production.hex. It fails to open the hex file. However, if I choose the four hex files separately, in that case I do not get any error messages, but the flash looks the same erroneous after programming it with the option "Erase & write". 

[Edvin]

Lex said:

but if you look at the second sentence in my post, it says: 

 Yes. Sorry. I missed that part when I started looking for possible issues.

 

Lex said:

Anyway, I have just found another clue! I get the following message in the desktop nRF Connect v3.6.1 - Programmer:

 So before you upload the merged .hex file into nRF Connect for Desktop -> Programmer, is the window to the right completely empty before you do this?

If not, try to click the "-" signs that appear when you hover your mouse over the regions in the right hand window before you drag and drop your merged .hex file into the programmer app:

Best regards,

Edvin

[Lex]

Yes, the right hand window is empty in the beginning. Here is how it looks in full window:

Notice the red text at the bottom of the window.

Below is a full window image about how it looks when I choose the files separately:

Even though this setup does not trigger an error message, I do not believe this is how it should look. There are three black sections on the image although there should only be two: one for the MBR parameters page and one for the bootloader settings page. I don't know where the extra section comes from...

[Edvin]

Hello,

It looks like you are correct. There is an issue with mergehex (probably introduced in version 10.12.x, where it sometimes generates invalid merged files. Until fixed, can you please try to remove nrfjprog  and mergehex, and use version 10.11.1 instead?

mergehex is part of nRF Command line tools, and you can find and download the different versions here.

Best regards,

Edvin

[Lex]

Hi Edvin,

Indeed, uninstalling version 10.12.1 of the nRF Command line tools and then installing 10.11.1 has partially solved the problem: nRF Connect -> Programmer does not complain anymore, and as soon as I program the merged hex file onto my device, the application starts running. Very nice!

But one problem still remains, which is that the way flash memory looks still resembles a horror movie. If you look at the picture below, on the right side you can see how the merged hex file (Production.hex) looks, according to the Programmer. The yellow, blue and green regions are correctly recognized as MBR, SoftDevice and Application. The red region is also correctly recognized as Bootloader region. However, there are three black lines instead of two: The first (from bottom) black section and the last are not recognized as any region. The middle one is an MBR Parameters region.

On the left side, you can see that the SoftDevice region is not recognized anymore, but instead, Application region is written there. The green section above it is also an Application region. It is followed by a red Bootloader region, a black MBR Parameters region and, an unrecognized region.

When on top of this I do a UART DFU process, then the memory looks like this:

Yellow: MBR Parameters;

Three green regions, each of them Application regions;

Red: Bootloader region;

1st black: MBR Parameters; 

2nd, 3rd and 4th black: not recognized.