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]

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?

[DarkMeans]

I dove into the bootloader code a bit to see if it would even start the application, and if I do a fresh Erase and Write in the programmer, the following change will get the application to boot once and it appears to act like it should.

After that, any subsequent resets will hard-fault at the nrf_dfu_flash.c file call of nrf_fstorage_init where it tries to initialize additional data.

I cannot figure out why this is happening only after a reset after the initial write/reprogram.  There must be something missing, I just currently cannot figure out what that might be.

[DarkMeans]

Based on the above code that was successful only the first time, but then would fail, I decided to massively rearrange the code spaces in both the NRF5 and the nRF Connect programs.  I decided to change it from 0x1000 to 0xC000 to be respectful of the possibilities of future changes to MCUBoot.

I also moved the new flash storage down to 0x000D0000 from 0x000F8000.

I cannot be 100% sure which of these was the root cause without further investigation, but right now I'm able to update and that's good enough for me to move on with some other tasks.

[Hieu]

Sorry, there was a holiday, and then I was out of office until now. It's good to know that you are satisfied for the time being, though not entirely good that we still haven't known what caused the issue yet.

If you ever returned to this, I suggest the next steps of the investigation to be:
- Check the nRF5 SDK bootloader code to see what trigger dfu_enter
- Check the partitioning of the NCS application