NCS and mcuboot: DFU over BLE: not enough image space on normal/smaller nRF52 chips

I have just spent a few weeks of work developing an application with NCS (2.0.0) for the second-biggest chip of the nRF52 series, the nRF52833. Now I have tried to activate DFU with mcuboot/mcumgr over BLE and I had to realize that the image size is too large. Of course, my application is quite demanding, I need BLE observer + peripheral role, data length extension, extended advertisements, various advertising sets, encryption, FOTA and a relatively large external library. So the with logging the size is around 300KB, without logging its 277KB.

When using the standard partitioning of the 515KB of the nRF52833, and mcuboot requiring two slots for BLE upgrades, I have a maximum slot size of 232KB, so it looks pretty impossible to squeeze all my features in. It may be possible to reduce the size a bit more (recommendations?), but I can't see it fitting into the available area, much less considering that i need to add features in the future.

But also when I look at the minimal sample (devzone.nordicsemi.com/.../ncs-dfu), which only has a LED service and mcumgr activated, and no other features it already uses up around 80% (or 75% without logging) of the flash space.

I wonder how Nordic expects us to develop useful, upgrade-able firmware for anything else than the nRF53 or nRF52840 with the Nordic Connect SDK?

The nRF528533 with 512KB flash is already relatively large, but developing anything useful with NCS for the smaller chips like nRF52811 & co looks pretty much impossible.

So, does that mean for all those chips, the majority of available Nordic BLE chips on the market today, we are stuck with the unmaintained old SDK??? Do I have port my whole shiny new NCS application back to the old SDK?

Or are there any other ways to reduce the flash space requirements in NCS (Yes, I have looked at "Memory footprint optimization" page)?

Parents
  • Hi Bruno,

    First of all, apologies for the delayed answer time. We are currently running with reduced staff due to the main summer vacation period here in Norway.

    As for you query: Unfortunately we do not have any simple solution for developers working with the "smaller" devices when creating an application that will support both many rather complex features and DFU. Usually we recommend to look into minimum configuration for BLE to reduce the size, but based on what you're writing I suppose you've already looked into this. Additionally since your application requires lots of advanced features, I do not think this reduction alone will help you in any meaningful ways.

    One option is to store the secondary partition (swap area) in the external flash, but this will increase both the complexity of the setup and the bill of materials. The second option, which you've already suggested yourself, is to use a larger chip such as the nRF5340 or nRF52840

    I know this is not the answer you were hoping for, but this is currently the best we can do. 

    Let me know if this clarifies your situation,

    Kind regards,
    Andreas

  • Andreas,

    We are in the same state having the nRF52811 BLE chip and wanting to do FOTA.  You had mentioned above that you might be able to store the secondary partition on an external flash.  Do you have any documentation or links explaining how that would work?  It may be possible for us to do that for now, since the board does have an external flash chip on it.  So any details on where to look would be greatly appreciated!

    Thanks,

    h.

Reply
  • Andreas,

    We are in the same state having the nRF52811 BLE chip and wanting to do FOTA.  You had mentioned above that you might be able to store the secondary partition on an external flash.  Do you have any documentation or links explaining how that would work?  It may be possible for us to do that for now, since the board does have an external flash chip on it.  So any details on where to look would be greatly appreciated!

    Thanks,

    h.

Children
Related