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]

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

[DarkMeans]

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.

[Hieu]

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.