nrf52dk_nrf52805 code examples RAM overflowed with Peripheral_LBS and DFU

[Dan in Colorado]

Working with an nrf52805.  Copied a simple example (peripheral_LBS) and found that RAM overflowed by ~2.2K  I note that the nrf52dk_nrf52805 is not listed as a "compatible" board. But using prj_minmal.conf I was able to compile.

But then I wanted to add DFU capability and now my RAM overflow is 22K! The module I'm targeting is a BC805M which appears to ship with a DFU capable version of a UART example. So I assume it must be possible to support DFU and have a very basic function - like reporting a single button - on an nrf52805.

How does one implement a lightweight app with DFU without overflowing 24kB of RAM?

Are there any code examples that support the nrf52805 with a small enough footprint to allow for DFU?

Using Visual Code with SDK v2.6.0 and toolchain 2.6.0

[AHaug]

Hi,

The short answer is that you won't be able to implement BLE FOTA on a device with less than 512kB of Flash in NCS due to no single-bank BLE FOTA support.

The longer answer:

For BLE FOTA you need dual bank DFU in NCS, to two reasons; one is fallback measures and the other is because the BLE stack/controller resides within the application and not as anything standalone. This means you need to keep the original version active while uploading the firmware. 

This means that you will have to store 2x your application within your available flash as well as a bootloader capable of performing DFU (lets use MCUboot as an example since that's the default we use). If you have a settings partition or any other custom storage partitions you will be left with something like

Maksimum flash on the SoC = MCUboot + 2x your application + settings + storage -> your application size = 1/2 (maximum flash - mcuboot - settings - storage) ~= 0.5 * (192k - 48k - 8k) = 68kB (yes, I know this is a very small application in NCS...). If you're able to reduce the size of MCUboot in half, you will get ~74kB for your application. 

The peripheral UART application in NCS v2.9.0 does already overflow with 967 Bytes for the nrf52dk/nrf52805 build target, but compiles with the minimal configuration and results in 132kB flash and 18.3kB RAM usage. I'm not sure if even a minimal MCUboot can fit within the remaining RAM, but it might.

Suggestion:

Add a minimal mcuboot with serial recovery support to do DFU over serial recovery and build the sample with minimal configuration (described closer in lesson 1 of https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/)

Kind regards,
Andreas

[Dan in Colorado]

Thanks for the fast response. 

132kB of Flash and 18kB of RAM for something as simple as a UART service?  That can't be right.  There must be a leaner development environment

[AHaug]

Hi,

Is there any reason for why you're not using the nRF52832, which you imply you have access to since you're building the emulated 52805 on the nRF52DK?

If the larger 52832/52833 is not within the scope, then for the nRF52805 you might consider to use the older nRF5SDK, which was the SDK that were bleeding edge at the point when the nRF52 family devices were launched. 

nRF Connect SDK does indeed require more resources of both RAM and Flash. I think this blog can give some more insight w.r.t this  Debunking misconceptions: A technical analysis of nRF5 SDK and nRF Connect SDK 

I was able to shrink the application somewhat more with the following additions to the minimal configuration

CONFIG_ISR_TABLES_LOCAL_DECLARATION=y
CONFIG_LTO=y

This left me with 123kB flash used instead (no changes in RAM use)

Kind regards,
Andreas
 

[Dan in Colorado]

Main reason for the 52805 is cost.  The lowest cost modules are built around them. I did see that nRF5 SDK seems to be more aimed at them.  Does it yield more compact/efficient code?

One important question, I see the nRF5 SDK is in "maintenance mode".  This would seem to imply that parts that require it are likely pretty old.  Is the 52805 slated to phase out? How many years can I expect to be able to source it?

[AHaug]

Hi,

Dan in Colorado said:

Main reason for the 52805 is cost.  The lowest cost modules are built around them.

Makes sense. I don't have any overview over how costly the nRF54L modules are, but there might be some in the nRF54L05 range that could be suited for your use as well (newest generation of short range MCU in the smallest and cheapest form factor). https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/keyfeatures_html5.html#ariaid-title1 

nRF5 SDK is more bare metal than nRF Connect SDK. NCS is based on Zephyr RTOS and has an RTOS under the hood. nRF5SDK does not have this. 

W.r.t maintenance mode for nRF5 SDK it simply means that no new development will be done on the SDK unless it is critical.

As far as I know none of the nRF52 family devices are slated to phase out in a quite a while (meaning many years), but if you want a rough estimate for this I recommend you to reach out to your regional sales director from Nordic. Let me know if you need their contact information.

Kind regards,
Andreas