This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Region RAM overflowed with stack

Hey everyone,

I'm developing an application using the IoT SDK. The first part of the application consisted of a normal BLE peripheral to interact with an android app. The second part consists of getting the peripheral connected to the internet through a gateway so that the system can be scaled.

I was compiling my application with the flag to drop unused sections, and had the IP stack initialization function commented out. Now that I'm done with the initial part of the application and uncommented the IP stack initialization function, I get the following error when I try to compile:

arm-none-eabi/bin/ld: region RAM overflowed with stack
ended making

I read in other questions that this could be fixed with one of two solutions:

  1. Finding places in my code that are using too much ram and trimming the fat. Thing is, I'm able to see in the generated map file what regions of the flash are being used but not ram regions, so I don't know where to start trimming. Also, when the linker fails with this message it doesn't output a map file, so I'm not able to see the space occupied by the entire code.
  2. Playing around with the stack and heap sizes. Supposedly after the softdevice is flashed I should be able to have 8kB ram available to me. I'm using the flags -D__HEAP_SIZE=2048 -D__STACK_SIZE=3440 in the compiler and assembler, and I can't increase the stack size past those 3440 bytes (even if i reduce the size of the heap).

Any ideas on what I'm doing wrong? I'm admittedly a noob at reading map files, so I'm using this utility to make it more understandable.

EDIT:

image description

Should't I be able to use all of those 8kB?

  • "region RAM overflowed with stack" means that your application requires too much RAM.

    If you have the chip version with 16kB and the SoftDevice use 8kB, the application doesn't have 8kB left.

    You need to include the call stack and heap into the calculation. Both of these are set to 2048 bytes, in most (if not all) of our examples. This leaves 4kB for the application.

    The S110 SoftDevice uses a maximum call stack of 1536 bytes (see Section 11.2 in the SDS for more info). With the stack size set to 2048, this leaves a maximum call stack of 512 bytes for the application.

    Heap is mainly used by malloc() and calloc(). The S110 SoftDevice doesn't use any heap, this is also true for ble_app_hrs, and most of the other examples in the SDK (maybe not the serializer examples). I'm not sure about the IoT SDK. You can try to decrease it.

    I think you should try to figure out how much RAM you have left with only the first part of your application.

    Total RAM usage will be RW-data + Zi-data. RW data is variables != 0, while ZI-data (zero initialized data) is variables set to 0. (The RW-data and Zi-data is displayed in the build output in Keil, I'm not sure about GCC. Add a new question about it?)

    The ipv6_coap_client example from the IoT SDK gives these figures:

    RW-data=228 ZI-data=8524

    This is in total 8752 bytes, and subtracting the call stack and the heap, the application ends up with 4656 bytes.

    Please let me know if anything is unclear.

  • Hey Petter,

    I was able to get this to compile by reducing the ammount of heap and ram I'm using. I think this lets the program use the remainder "free" ram, no? Thing is I get really weird behaviour with my application now. For example: in my application I have to poll for values from external inputs. I'm using the application timers as per your examples. When I have the IP stack initialized the timer only runs two times and then stops. When it runs, the results are not what I'd expect. Is this a sign of low memory?

  • The application can use the remainder of RAM, but the amount is fixed after compilation. The size of the call stack changes at run time. I'm not sure what could cause this, and I don't see why low memory would cause it. I feel we are moving into a new question here, could you add it separately? Maybe link to this one. It would be helpful if you could upload your complete project so we can have a look, you could also elaborate a bit on what result you expect, and what the results are.

  • Uploading the whole project is a big nono since my company's policy prevents me doing it. But I'll try to be more specific. I've also added this new question that is related to this one.

Related