• State Verified Answer
  • Replies 2 replies
  • Subscribers 74 subscribers
  • Views 621 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 305922
Options

Tracking down ROM memory bulk

Anthony W

I have an application that I'm running on the nRF52832 which, by itself, is not terribly large: my source code compiled is around 11KB. However, with all the features compiled in, it balloons to 231KB. I found this out when I tried to enable the MCUBoot, which I wanted to incorporate for FOTA, but with that feature enabled the flash image is now too large (it doesn't give any details, but I'm guessing it's trying to ensure it fits in one of the two 200KB image partitions).

I used the memory report tool in VSCode, which is really nice. I was surprised to see almost 51KB used by the BLE libraries, which seems like a lot, I wonder if that's typical? (In all, NCS is using just over 100KB.)

The other block I don't understand falls under "No paths", where there are plenty of nondescript identifiers, like ":/sym_XMQQMVD4MD6DRWNW2DWSCGOMJHFY3IX7NXUHTGI". This node takes up another 100KB.

From these, it's not terribly clear where I should start trimming. With respect to NCS, the biggest node is coming from BLE, but there's nothing obvious I can see to disable. The rest of the utilization is spread over a lot of features, which I can start to disable but I think it'll be tough to bring it down 31KB, plus whatever MCUBoot and FOTA are going to require. And regarding the "No paths" node, I don't even know if these are things I can look into trimming, or if they're somehow byproducts of the other compiled code. There's no indication where they're coming from.

So the questions:

  • Does this utilization seem normal? I would have expected much less. Debug symbols are (or should be) disabled (although I originally checked the "Enable debug features" checkbox, I'm not sure if that is completely undone by removing debug options in the project config).
  • Can you give an indication what those "No path" items are, and how to track down their origin?
  • Do you have general advice for "trimming the fat", so to speak?

Here's a screenshot of the report. I also attached the ROM report and a project config.

ROM.json

Project config

Thank you for your help!

  • +1

    Hi,

    my source code compiled is around 11KB. However, with all the features compiled in, it balloons to 231KB

    What are the configurations before and after here?

    I was surprised to see almost 51KB used by the BLE libraries, which seems like a lot, I wonder if that's typical?

    When I build out Bluetooth: Peripheral LBS sample, I get 39kB Bluetooth ROM for prj.conf and 31kB Bluetooth ROM for prj_release.conf.

    I found this out when I tried to enable the MCUBoot, which I wanted to incorporate for FOTA, but with that feature enabled the flash image is now too large (it doesn't give any details, but I'm guessing it's trying to ensure it fits in one of the two 200KB image partitio

    Yes, FOTA with MCUboot ca halves available space, as you must have dual slots.

    Do you have general advice for "trimming the fat", so to speak?

    Memory footprint optimization docs and memory footprint blog.

    Does this utilization seem normal? I would have expected much less. Debug symbols are (or should be) disabled (although I originally checked the "Enable debug features" checkbox, I'm not sure if that is completely undone by removing debug options in the project config).

    Yes, since the nRF Connect SDK is build on the Zephyr RTOS, it will take more space than if it was bare-bone.
    That is the cost of functionality.

    For what is normal, the best I can do is point to our prj_release.conf configurations in our samples, as these try to show how to configure samples with less features enabled.

    Can you give an indication what those "No path" items are, and how to track down their origin?

    If I take on on random, for example "sym_NFDFVOR5BUFND4TNTGYIYR4ARXJRXWSQ4PVFUKY" from my peripheral_lbs sample.

    Then I right click on my build folder and "find in folder" -> search for "sym_NFDFVOR5BUFND4TNTGYIYR4ARXJRXWSQ4PVFUKY"

    I find this in zephyr_fimnal.map:

    And this is from "ncs/nrfxlib/mpsl/lib/cortex-m4/soft-float/libmpsl.a", I would guess.

    Did I answer your questions?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    This was all very helpful. Yes, I see the BT configuration is pretty typical then. My application uses three roles (central, peripheral, observer), SMP, and a number of other things. I wanted to double check I wasn't doing something obviously dumb though, since the device I'm using isn't terribly small I didn't really expect to run into storage issues. The sensor-only units at least can be made small enough to enable FOTA, but for the more complicated units I'll probably switch to the nRF5340 instead, I'm just using too many features.

    Thank you for the other resources as well, they were extremely useful.

Related
Terms of service