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

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

Hieu — Wed, 12 Jun 2024 13:30:50 GMT

Yes, the scenario you mentioned is certainly possible. If you want to investigate this, you might want to dive into app_is_valid() and see which of the check inside is failing.

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

DarkMeans — Mon, 10 Jun 2024 20:03:43 GMT

Thank you, I do appreciate your responses still.

The part it was getting locked up on was always this, even though everything was signed, it never seemed to want to treat the application as valid.

    if (!app_is_valid(crc_on_valid_app_required()))
    {
        NRF_LOG_DEBUG("DFU mode because app is not valid.");
        return true;
    }

Once that was placed, it worked 100% of the time and didn't just constantly enter the bootloader.

Since we are using a direct serial line communication, I don't see any way that the system could be bricked, but it could certainly get loaded with a bad program and lock up.

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

Hieu — Thu, 23 May 2024 13:28:08 GMT

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

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

DarkMeans — Tue, 21 May 2024 22:06:13 GMT

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.

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

DarkMeans — Fri, 17 May 2024 11:09:53 GMT

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.

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

DarkMeans — Thu, 16 May 2024 23:07:04 GMT

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?

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

Hieu — Tue, 14 May 2024 11:04:25 GMT

[quote user="DarkMeans"]

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.

[/quote]

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\.

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

DarkMeans — Mon, 13 May 2024 15:17:12 GMT

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.

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

DarkMeans — Mon, 13 May 2024 14:39:36 GMT

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.

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

Hieu — Mon, 13 May 2024 11:23:21 GMT

Hi DarkMeans,

[quote user="DarkMeans"]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.
[/quote]

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.

[quote user="DarkMeans"]

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.

[/quote]

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.

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

DarkMeans — Wed, 08 May 2024 22:22:15 GMT

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.

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

DarkMeans — Wed, 08 May 2024 22:14:42 GMT

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.

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

Hieu — Fri, 26 Apr 2024 12:10:54 GMT

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

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

AntonZ — Fri, 26 Apr 2024 06:41:40 GMT

Hi Hieu,

I've replied, yet not to your response, sorry.
Can you please comment below?

Thanks,
Anton

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

AntonZ — Thu, 25 Apr 2024 13:24:49 GMT

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

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

Hieu — Thu, 25 Apr 2024 13:18:00 GMT

Hi AntonZ,

May I ask why you want to implement the bootloader in the nRF5 SDK? It is possible, yes, but I don't know whether that's the best option for most use-cases or not.

In any cases, if I understand the situation right, the bootloader is custom made by you, so I don't really know the background why it expects two files and am not sure how to help you with that.
I know the bootloaders provided in the nRF5 SDK can update the application using one single binary file just fine.

Hieu