Loading nRF Connect SDK app via UART using nRF5 SDK secure bootloader

[AntonZ]

Hi,

we are facing an issue of loading the application written with nRF Connect SDK to the nRF52840 which has nRF5 SDK's secure bootloader.
Update process should be performed by another MCU via UART (so two files are used for a single update: init packet and the image itself).

Based on my request posted previously, we decided to use the nRF5 SDK's bootloader.

Now, as I can see the output of the nRF Connect SDK is a single binary, yet the bootloader expects two files.

Since the bootloader and all application logic (of another MCU) is already implemented, is there some easy way to be able to send updates to the target Nordic chip?

[AntonZ]

Hi Hieu,

No, I might've put the wrong explanation: the bootloader is taked from nRF5 SDK (secure bootloader) which is triggered by another external MCU.

Two files I'm talking about are: 1. Init packet; 2. FW binary.

Both files are normally generated by nrfutil. But, as I understand, nrfutil can't generate such package for the app created with nRF Connect SDK.
So, how is is possible to send such application to the secure bootloader?

Thanks,
Anton

[Hieu]

Hi Anton,

I see. nRF Util should still be able to generate such a package for the app created with nRF Connect SDK (NCS). Please give it a try.
Note that you might have to change the DFU package type to SoftDevice, because the NCS application starts at 0x1000, where the SoftDevice starts in the nRF5 SDK.

By the way, if you are not heavily invested into this yet, I still recommend you consider if the nRF Connect SDK solutions are feasible for your project.

Regards,

Hieu

[DarkMeans]

Hello, Hieu.  This is a project I'm working on with Anton.

A few additional questions on this.  Using the nRF5 SDK bootloader, I cannot seem to program it and have it work using the "nRF Connect for Desktop" Programmer tool.  It always gives an error with the size.

I can program it directly from Segger, but I need to find a way to program it via a programming tool.

[DarkMeans]

One other question is relating to the programming.

In order to target at addres 0x1000, we are building using nRF Connect v2.5.0 and trying to point the application to the proper memory location using the following KConfig flag.
CONFIG_FLASH_LOAD_OFFSET=0x1000

The nrfutil command used to create the package is as follows:
nrfutil pkg generate --application build/zephyr/zephyr.hex --application-version 0 --hw-version 52 --sd-req 0x0 --key-file private-key.pem zephyr-application.zip

Using this, the code does appear to load, but nothing is actually starting at offset 0x1000.  It starts 8-bytes shy, I think, at 0x0FF8.  The "nRF Connect for Desktop" Programmer output is below.

I would suspect that it would be starting at address 0x1000, but it isn't, and the application isn't starting.

If I build the application directly in VSCode and program it without the CONFIG_FLASH_LOAD_OFFSET set, it starts up and works every time, we just cannot update it in the field as there is no bootloader installed.

[Hieu]

Hi DarkMeans,

DarkMeans said:

A few additional questions on this.  Using the nRF5 SDK bootloader, I cannot seem to program it and have it work using the "nRF Connect for Desktop" Programmer tool.  It always gives an error with the size.

This is not necessarily an error. The image you generated for DFU with the nRF5 SDK bootloader often includes some data in the UICR region, where the address is outside of the flash memory address, so you see such a warning.

To confirm if that is the case, or if it is something wrong, you can open the file with a hex editor, and see what kind of data lies outside of the flash memory address range.

DarkMeans said:

Using this, the code does appear to load, but nothing is actually starting at offset 0x1000.  It starts 8-bytes shy, I think, at 0x0FF8.  The "nRF Connect for Desktop" Programmer output is below.

I would suspect that it would be starting at address 0x1000, but it isn't, and the application isn't starting.

In the nRF5 SDK boot solution, the MBR reserves the 0x0000-0x1000 address space, and has some data at the very end, at 0x0FF8. What you see is likely that the nRF Programmer tool seeing continuous non-FF data starting from 0x0FF8 and visualize it as a continuous chunk.

To check if your application actually starts from 0x1000, you could use a hex editor.

I recommend you add logging to your bootloader to check if the MBR has jumped to the bootloader, and if the bootloader can jump to the application.

For your reference, my colleague Vidar discuss the details of using a NCS application with a nRF5 SDK bootloader here:  RE: Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application . Please take a look to see what the considerations in such a scenario are.

[DarkMeans]

Thank you, that 0x0FF8 explanation makes the most sense.  Programming it manually through your nRF Connect Programmer, it has an address starting at 0x1000.

I'll take a look at the other link and respond back if I have additional questions.

[DarkMeans]

When I program the project from the Segger programmer (using the ! button), this is the code that is loaded to my chip.  I have yet to recreate this memory structure using just the nRF Connect for Desktop Programmer tool.  I suppose that is part of the issue, because when I program the bootloader from the Segger programmer, I can connect to it with the external microcontroller and perform a serial update.

Using the nRF Connect for Desktop Programmer tool, it only programs the hex file at 0xF8000 and nothing in the 0x0000 range, and it won't connect to the external microcontroller.

[Hieu]

DarkMeans said:

When I program the project from the Segger programmer (using the ! button), this is the code that is loaded to my chip. [...]

Using the nRF Connect for Desktop Programmer tool, it only programs the hex file at 0xF8000 and nothing in the 0x0000 range, and it won't connect to the external microcontroller.

Do you mean you get the 0x0000-0x1000 region by flashing from inside SEGGER Embedded Studio (SES)? The bootloader SES projects are setup to flash both the MBR and the compiled bootloader, and that's why you get the MBR.

When flashing the hex files manually via nRF Connect or any programming tools, you need to add the MBR hex file.

In the nRF5 SDK, the MBR is located at <sdk_root>\components\softdevice\mbr\hex\.

[DarkMeans]

Alright, I have found the MBR for the bootloader and that can be added at the same time.

Without a bootloader and the address set to 0x0000 for the application, everything boots and works fine.

If I add the bootloader, the MBR, and the address has been changed to 0x1000 using the CONFIG_FLASH_LOAD_OFFSET=0x1000 configuration, the application will not load.

 

Looking into this further, it would appear that I needed to generate a bootloader settings file, which I have done and added with the command below.

nrfutil settings generate --no-backup --family NRF52840 --application build/zephyr/zephyr.hex --application-version 3 --app-boot-validation NO_VALIDATION --bootloader-version 2 --bl-settings-version 2 settings.hex

Still, it will not boot.  I believe that the missing link might be that I haven't created the "MBR params page" hex file.  I however cannot figure out how to create it.

Does it sound like I am on the right track with needing this "MBR params page" file?