This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 RAM power off - How to know which banks/sections are in use

Hello -

We are working with the nRF52840 and SDK v17.0.0 and tuning our power consumption during System ON sleep. We understand how to wakeup the device using the RTC and also how to selectively power off RAM banks and sections. We know that powered off RAM sections lose their contents.

In order to reduce power consumption in System ON sleep, we'd like to power off unused RAM. What we don't understand is how to know at runtime what areas of RAM are currently in use and hence should not be powered off across System ON sleep. We use malloc() for all our dynamic allocations. The SoftDevice and SDK also allocate memory. The applications we support vary in complexity, so it is likely that we'll need some type of general solution. We are also using FreeRTOS with tickless idle enabled, so the System ON sleep will be entered from within the tickless idle function.

At any given time during execution, how can we know which RAM sections can be safely powered off? Are there memory allocators in the SDK and/or linker script features (aside from a .noinit section) that can be leveraged?

Regards,

Brian

Parents
  • Hi Brian,

    To control RAM power with section granularity, you need an allocator that is able to work with section-sized RAM blocks. Take a look at balloc library in SDK - it does (almost) exactly what you're looking for.

    Create a linker section that starts at RAM section boundary, then change NRF_BALLOC_DBG_DEF macro in balloc.h to allocate _nrf_balloc_pool_mem items in that section. You also will need a small intermediate layer that will create a map of allocated blocks. Note that in debug mode each block will have a debug header, thus it will not be section-sized, so you need to disable RAM power control in debug mode.

    SoftDevice uses a static linear memory region from the start of RAM. When SoftDevice is disabled, you can safely turn its memory off, except of first section (0x20000000).

  • Dmitry -

    Thanks again for answering our questions. Before I close this issue out, I'd like to clarify if it is possible or not to override the malloc() and free() functions provided through the nRF5 SDK (via GCC). If we can do that then it is straightforward for us to track all allocations that use those functions.

    Regards,

    Brian

  • Yes, you can define your own malloc() and free() implementations. The linker will look into your files first - if they're defined, it will not search standard libraries for them.

Reply Children
No Data
Related