BLE 5.1 on small devices with BLE Bootloader

[H.Marske]

Hi,

We are currently developing a BLE device (HW and SW) using the NRF52811.

As we want to be able to update the device via FOTA we need to have the Bootloader to have the BLE-Stack.

We now have the BLE-Stack twice in our Program so it exceeds the maximum flash size.

We dont really want to switch the SoC´s as we want the DirectionFinding Feature and the next device capable is the nrf52833

 wich is quite a bit more expensive.

Is there any way to compress the Bootloader or maybe use the same BLE-Stack for both Application as well as bootloader?

Is there any way to compress the Bootloader to only have the BLE-DFU capabilitites?

Kind regards

H.Marske

[Hieu]

Hello H. Marske,

Are you using the nRF Connect SDK and MCUboot? I am honestly quite surprised you managed to add BLE to the bootloader in this setup.

Have you tried building MCUboot with its minimal configuration?

Technically, there is a bootloader smaller than MCUboot: Nordic Secure Immutable Bootloader (NSIB, or b0).
Besides these, there is the nRF52820. It is bigger than the nRF52811, (should be) cheaper than the nRF52833, and also supports Direction Finding.

There are also a few DevZone cases on possible alternative when hitting flash size limit:
Add mcuboot to connect SDK BLE sample "central and peripheral"
RE: How to reduce the size of an executable file?

Another option would be attempting to have a bootloader based on the nRF5 SDK on the device instead. There is some space saving potential there. Please keep in mind that you will lose the secure Root of Trust features that comes with the nRF Connect SDK bootloaders.
Refer to Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application 

Other than the above options, likely due to the limitation you have seen, we don't really consider MCUboot or NSIB supported on the nRF52811. We are updating our documentation to reflect that fact.

I am very sorry for the lack of good news.

Best regards,

Hieu

[hmolesworth]

Following on from Hieu's comments, another option is to accept a fixed Bootloader and SoftDevice and only update the application by using the application to download a new version of itself, unless there is insufficient room for 2 versions of the application (without softdevice) in flash memory. In that latter case the Bootloader could use the single Softdevice API directly to download a new application on top of the outdated application by restarting itself in Bootloader-with-SD mode, though I have not seen this done anywhere. The Bootloader would be compiled like an application with the softdevice included as the softdevice would use the exact same memory addresses as the real application. The OTA update would have to just overwrite the application code which is easy enough to separate from the application's own identical copy of the softdevice. The softdevice has no dependence on whether the Bootloader is in charge or the application is in charge if the vectors are managed by the Bootloader; the softdevice vector hooks to the Bootloader vector table which chooses whether in Bootloader or application mode, in the latter case forwarding vectors. ie it would be simpler to always have the "application" vector table be in the Bootloader; now the softdevice only talks to Bootloader vectors, which in turn can forward to the real application vectors in vector table in the application.

Immediately following the vector table location at the start of the both the application and Bootloader functions and variables that have to be accessed by the other via "vector" pointers when the actual location in the application changes from build to build allows more space savings when both Bootloader and application would otherwise have duplicated code and indeed allows for patch fixes for the Bootloader.