Putting my app on a (RAM) memory diet

Question

I'm running out of RAM in my 51822 app and I need to take a look at what's using RW and ZI memory. Very little memory is being allocated with malloc. The rest is allocated at build time. How can I generate a memory map at build time that tells me the size of the various static and global objects?

Ole Morten · Accepted Answer

You do have a lot of questions here, so I'll try to answer them sequentially: 
 
 For completeness, Keil will put a .map file in the _build folder as long as the "Linker listing" options are on on the "Listing" tab of the target options. 
 arm_startup_nrf51.s contains the definitions of the heap and the stack, each being 2 kB by default, and this is therefore the reason it shows up with 4 kB in your map file. If you know that you don't use 2 kB of heap, feel free to reduce the heap size. The memory usage of S110 itself is given in the Softdevice Specification (1.5 kB of stack, no heap), and no heap is used by the SDK. 
 Some of the initalization macros used in main.c contains a static buffer for data storage. This applies for for example BLE_STACK_INIT, APP_TIMER_INIT, APP_BUTTON_INIT and friends, and this is most likely the cause of the 972 bytes used in main. You can for example take a look at the timer queue size, as explained here and the maximum number of timers, since this is usually a big part of the main memory. 
 
 Apart from this, your map file should contain a listing of the symbols defined in main, and how much memory each consumes, like this: 
 .bss 0x200020f0 Section 776 main.o(.bss)
APP_TIMER_BUF 0x200020f0 Data 576 main.o(.bss)
EVT_BUFFER 0x20002330 Data 80 main.o(.bss)
app_gpiote_buf 0x20002380 Data 20 main.o(.bss)
m_tps 0x20002394 Data 10 main.o(.bss)
m_ias 0x200023a0 Data 16 main.o(.bss)
m_lls 0x200023b0 Data 20 main.o(.bss)
m_bas 0x200023c4 Data 24 main.o(.bss)
m_ias_c 0x200023dc Data 12 main.o(.bss)
m_battery_sim_cfg 0x200023e8 Data 16 main.o(.bss)
 
 For this application, the timer buffer is the biggest consumer in main, with the event buffer for the softdevice being second. Also the app_gpiote structure consumes a bit, as well as the different services. 
 Another module that might easily consume some RAM is the bond manager. It needs to fit all bond information in RAM before writing to flash, so by reducing the max number of bonds you can store, you can reduce its RAM consumption. 
 PS: You make it much more likely to get quick answers if you edit your original question instead of continuously posting new information as answers, since the answers moves the question out of the "Unanswered" category. :-) I'd also be very happy if you could go back and take a look at other questions you have asked and accept an answer to those that you consider solved. That makes it a lot easier for others to find useful information!

Putting my app on a (RAM) memory diet

Top Replies