Am I allowed to eat up a little bit of RAM space from S110 ?

[Jean-Louis Bonnaffé]

Hello,

I am developing on top of S110, for nrf51822_xxaa, building with GCC. And as my code is growing, even after mapping inspection, gcc optimizations, stripping, heap reduction and using nano lib, I am still reaching the infamous link error :

region RAM overflowed with stack

According to gcc_nrf51_common.ld, it seems that the RAM "user" area (.data, .bss, .heap, .stack) is full.

Yes, it sounds like a very common topic, but after reading the S110 specification, chapter 11, I noticed that the RAM is divided in two areas :

R0 [0x2000 0000  - APP_RAM_BASE] : MBR, SoftDevice
R1 [APP_RAM_BASE -  0x2000 4000] : Application, heap, stack

and the doc says I could reduce APP_RAM_BASE down to 0x200019D8, which would free a few bytes.

So, I've tried updating gcc_nrf51_s110_xxaa.ld as follows :

RAM (rwx) :  ORIGIN = 0x200019D8, LENGTH = 0x2628

that removes the error but application doesn't boot. I suppose the SoftDevice should be told about the attribute table size... any clue what is the API to do so ?

[Nick Pelis]

Depending on your requirements, you may be able to shrink the size of the heap and stack. Check out arm_startup_nrf51.s.

Also keep in mind indirect function calls (e.g., C++ code, structs of function pointers) are complicated for the compiler to implement on the Cortex-M0 architecture, resulting in more assembly instructions and larger code. Same applies for indirect memory reads/writes (e.g. pointers to arrays, arrays of pointers, double-pointers, etc.).

[Jean-Louis Bonnaffé]

reducing the stack size in the gcc_startup_nrf51.s did the trick - Thanks a ton, Nick !

[John]

Just to expand on part of Nick's answer: If you are not using dynamic memory allocation such as malloc, you can set the heap to zero and get back 2K of RAM.