Stack overflow - ‘Interrupts’ your ‘flow’

This is my first step to blogging world, where words matter and quality counts. I was befuddled while searching for my first blog topic. For last one month I was working on PIC 16F877 faced some challenges which i was not aware of. So finalized that I'm going to write on issues I faced.

In this blog would like to start with stack-overflow in embedded-systems. First of all, I gone through Wikipedia description of stack overflow. There’s nothing wrong with the description – it’s just incomplete from an embedded systems perspective. So decided to investigate on that and start a blog.

What’s your stack size set to?

Most embedded systems compilers are designed to work with a particular family of processors. The low end of the family may have a tiny amount of memory (e.g. 128 bytes). For example 8 bit PIC architecture is that the stack size is fixed. It varies from a depth of 2 for the really low end devices to 31 for the high end 8 bit devices. The most popular parts (such as the 16F877) have a stack size of 8.

Which stack is overflowing?

Many processors implement multiple stacks. A typical separation is a call stack (upon which the return addresses of functions are stored) and a data or parameter stack (upon which automatic variables are stored). Once you’ve made the determination which stack is overflowing then finding out exactly what gets placed on that stack will help lead you to the solution to your problem. If you can see no high level language construct that is causing the problem, then the single most likely cause of your misery is an interrupt service routine. 

Reasons

1.  An interrupt service routine can use up a huge amount of space on the stack. This problem is arise if your system allows interrupts to be nested (that is, it allows an ISR to itself be interrupted).
2. Certain library functions (like printf and companions) can use an enormous amount of stack space.
3. Calling functions in nested manner, going beyond your stack size.
4. If you are writing partially in assembly language, and you failing to pop every register that you pushed? This often occurs if you have more than one exit point from a function or ISR.
5. If you are writing entirely in assembly language, and you are not setting up the stack pointer correctly, and you don't know which way the stack grows?
6. Have you made the mistake of programming a micro-controller that you don’t understand? For example, low end PIC processors have a tiny call stack which is easily overflowed. If you are programming a PIC and don’t know about this limitation, then I’m not surprised you are having problems.

If none of the above solve your problem, then you are most likely in to a stack over-write problem. That is, a pointer is being de-referenced that results in the stack being overwritten. This can often arise when you allocate an array on the stack and then access an element beyond the end of the array.

Next blog we will see how to compute your stack size.