What happens when microcontrollers run out of RAM?
In general the stack and the heap crash in to each other. At that point it all gets messy.
Depending on the MCU one of several things may (or will) happen.
- Variables get corrupted
- The stack gets corrupted
- The program gets corrupted
When 1 happens you start getting strange behaviour - things not doing what they should. When 2 happens all manner of hell breaks loose. If the return address on the stack (if there is one) is corrupted, then where the current call will return to is anyone's guess. At that time basically the MCU will start doing random things. When 3 happens again, who knows quite what would happen. This only happens when you're executing code out of RAM.
In general when the stack gets corrupted it's all over. Just what happens is down to the MCU.
It might be that trying to allocate the memory in the first place fails so the corruption doesn't happen. In this case the MCU might raise an exception. If there is no exception handler installed, then most often the MCU will just halt (an equivalent of while (1);. If there is a handler installed, then it might reboot cleanly.
If the memory allocation does go ahead, or if it tries, fails, and just continues with no memory allocated, then you're into the realms of "who knows?". The MCU might end up rebooting itself through the right combination of events (interrupts caused that end up resetting the chip, etc), but there's no guarantee of that happening.
What there can usually be a high probability of happening, though, if it's enabled, is the internal watchdog timer (if one exists) timing out and rebooting the chip. When the program goes completely AWOL through this kind of crash the instructions to reset the timer generally won't be run, so it will time out and reset.
An alternative view : Microcontrollers don't run out of memory.
At least, not when programmed properly. Programming a microcontroller is not exactly like general purpose programming, to do it properly you have to be aware of its constraints and program accordingly. There are tools to help ensure this. Search them out and learn them - at least how to read linker scripts and warnings.
However as Majenko and others say, a badly programmed microcontroller may run out of memory, and then do anything including infinite loop (which at least gives the watchdog timer a chance to reset it. You did enable the watchdog timer, didn't you?)
Common programming rules for microcontrollers avoid this : for example, all memory is either allocated on the stack or statically (globally) allocated; "new" or "malloc" are forbidden. So is recursion, so that the maximum depth of subroutine nesting can be analysed and shown to fit in the available stack.
Thus the maximum storage required can be computed when the program is compiled or linked, and compared with the memory size (often encoded in the linker script) for the specific processor you are targetting.
Then the microcontroller may not run out of memory, but your program might. And in that case, you get to
- rewrite it, smaller, or
- pick a bigger processor (they are often available with different memory sizes).
One common set of rules for microcontroller programming is MISRA-C, adopted by the motor industry.
Best practice in my view is to use the SPARK-2014 subset of Ada. Ada actually targets small controllers like AVR, MSP430 and ARM Cortex reasonably well, and inherently provides a better model for microcontroller programming than C. But SPARK adds annotations to the program, in the form of comments, which describe what the program is doing.
Now the SPARK tools will analyze the program, including those annotations, and prove properties about it (or report potential errors). You don't have to waste time or code space dealing with erroneous memory accesses or integer overflows because they have been proven to never happen.
Although there is more up-front work involved with SPARK, experience is showing it can get to a product faster and cheaper because you don't spend time chasing mysterious reboots and other strange behaviour.
A comparison of MISRA-C and SPARK
I really like Majenko's answer and +1'd it myself. But I want to clarify this to a sharp point:
Anything can happen when a microcontroller runs out of memory.
You really cannot rely on anything when it happens. When the machine runs out of stack memory, the stack most probably becomes corrupted. And as that happens, anything can happen. Variable values, spills, temp registers, all become corrupted, disrupting program flows. If/then/elses can evaluate incorrectly. Return addresses are garbled, making the program jump to random addresses. Any code you've written in the program may execute. (Consider code like : "if [condition] then {fire_all_missiles();}"). Also a whole bunch of instructions you haven't written can execute when the core jumps to a nonconnected memory location. All bets are off.