Tips for reducing ROM size. (NCS 2.7, nrf52840

NCS 2.7.0
NRF52840
Major subsystems and drivers used: littlefs, nvs, bluetooth, nanopb, spi, spi_nor, i2c, logging, flash_map, multithreading

I'm finding the built image to be 486 KB after size optimization (-Os). The image includes a 130 KB firmware for an external component. That leaves the application size as 366 KB, which seems rather large. In addition, the image is expected to grow as motion algorithms are added.

Looking at the memory report some of the largest items are
Nordic Proprietary Libraries 76.4 KB
bluetooth 47 KB + net 2 KB
Hidden 43.48 KB
No paths 38.2 KB
littlefs 16.8 KB
nanopb 5.7 KB
logging 4.27 KB
nvs 2.9 KB

I'm working with NRF52840 which has a 1MB capacity. I want to have mcuboot with DFU so at least 32KB (?) would be allocated for mcuboot, I want to reserve at least 12KB for NVS. The space available for 2 slots is therefore limited to 980KB or 490 KB max image size.

Is there any way to reduce the size of "Nordic Proprietary Libraries" ?
Is there any way to reduce the size of bluetooth?
What is going on with "Hidden" and "No path" items, why aren't they combined with their original source file?

I'm thinking my best path forward might be to use sysbuild to add a separate section for the external component's firmware. That would make the regions
32 KB mcuboot
132 KB external firmware
12 KB NVS
420 KB application
4 KB swap move buffer
420 KB update slot

With the NRF SDK 5 architecture the images were divided into the bootloader, softdevice (bluetooth, nordic proprietary libraries, etc) and application which made the updatable components smaller. Now with these monolithic images, much more space needs to be reserved for the update slot, effectively making the usable application size much smaller. Basically at this point the application that we previously built on nrf52832 won't even fit in nrf52840 with twice as much flash!

Parents
  • Hello, and sorry for the late reply. 

    We have seen requests for separating out the softdevice like we had in the nRF5 SDK, but unfortunately, we currently have no solution for that. 

    One alternative, that we also use on our DKs, is to have an external flash chip, that you can use as the update slot. That frees up a lot of place for your application. 

    Best regards,

    Edvin

  • Can you explain why the "Nordic Proprietary Libraries"  is so large?

    Is there any tutorial or example on something like an additional updatable region for the external firmware?

    What is the source of "Hidden" and "No path"  ?

    Using our external flash for image update is an option, but it will require we reduce the capacity available to the application. 

    Its pretty sad that we went to a chip with 2x the internal flash capacity and because of Zephyr we will still end up making a product that is less capable than the previous generation.  

    My clients will be really disappointed, the expectation I set was that Zephyr would be equal to or superior to the legacy libraries.  

Reply
  • Can you explain why the "Nordic Proprietary Libraries"  is so large?

    Is there any tutorial or example on something like an additional updatable region for the external firmware?

    What is the source of "Hidden" and "No path"  ?

    Using our external flash for image update is an option, but it will require we reduce the capacity available to the application. 

    Its pretty sad that we went to a chip with 2x the internal flash capacity and because of Zephyr we will still end up making a product that is less capable than the previous generation.  

    My clients will be really disappointed, the expectation I set was that Zephyr would be equal to or superior to the legacy libraries.  

Children
No Data
Related