4
votes

I'm writing a firmware for a Atmel XMEGA microcontroller in c and I think I filled up the 4 KB of SRAM. As far as I know I only do have static/global data and local stack variables (I don't use malloc within my code).

I use a local variable to buffer some pixel data. If I increase the buffer to 51 bytes my display is showing strange results - a buffer of 6 bytes is doing fine. This is why I think my ram is full and the stack is overwriting something.

Creating more free memory is not my problem because I can just move some static data into the flash and only load it when its needed. What bothers me is the fact that I could have never discovered that the memory got full.

Is it somehow possible to dected (e.g. by reseting the microcontroller) when the memory got filled up instead of letting it overwrite some other data?

4

4 Answers

3
votes

It can be very difficult to predict exactly how much stack you'll need (some toolchains can have a go at this if you turn on the right options, but it's only ever a rough guide).

A common way of checking on the state of the stack is to fill it completely with a known value at startup, run the code as hard/long as you can, and then see how much had not been overwritten.

The startup code for your toolchain might even have an option to fill the stack for you.

Unfortunately, although the concepts are very simple: fill the stack with a known value, count the number of those values which remain, the reality of implementing it can require quite a deep understanding of the way your specific tools (particularly the startup code and the linker) work.

Crude ways to check if stack overflow is what's causing your problem are to make all your local arrays 'static' and/or to hugely increase the size of the stack and then see if things work better. These can both be difficult to do on small embedded systems.

1
votes

"Is it somehow possible to dected (e.g. by reseting the microcontroller) when the memory got filled up instead of letting it overwrite some other data?"

I suppose currently you have a memory mapping like (1). When stack and/or variable space grow to much, they collide and overwrite each other (*).

Another possibility is a memory mapping like (2). When stack or variable space exceeds the maximum space, they hit the not mapped addr space (*). Depending on the controller (I am not sure about AVR family) this causes a reset/trap or similar (= what you desired).

  [not mapped addr space][   RAM  mapped  addr  space   ][not mapped addr space] 
(1)                      [variables --->  *   <--- stack] 
(2)                     *[ <--- stack   variables --->  ]* 

(arrows indicate growing direction if more variable/stack is used)

Of course it is better to make sure beforehand that RAM is big enough.

1
votes

Typically the linker is responsible for allocating the memory for code, constants, static data, stacks and heaps. Often you must specify required stack sizes (and available memory) to the linker which will then flag an error if it can't fit everything in.

Note also that if you're dealing with a multithreaded application, then each thread has it's own stack and these are frequently allocated off the heap as the thread starts.

Unless your processor has some hardware checking for stack overflow on it (unlikely), there are a couple of tricks you can use to monitor the stack usage.

  • Fill the stack with a known marker pattern, and examine the stack memory (as allocated by the linker) to determine how much of the marker remains uncorrupted.
  • In a timer interrupt (or similar) compare the main thread stack pointer with the base of the stack to check for overflow

Both of these approaches are useful in debugging, but they are not guaranteed to catch all problems and will typically only flag a problem AFTER the stack has already corrupted something else...

0
votes

Usually your programming tool knows the parameters of the controller, so you should be warned if you used more (without mallocs, it is known at compile time).

But you should be careful with pixeldata, because most displays don't have linear address space.

EDIT: usually you can specify the stack size manually. Leave just enough memory for static variables, and reserve the rest for stack.