I am currently writing code where it is necessary to use cache memory. I declared a pointer that points to the address 0x01000000. There are no compiler errors and I am fairly certain my code is correct. However, now I am at the stage where I need to test my code to see if it does what I want it to. When I try to step through it using IAR's debugger. Specifically, when I try to step through the portion of the code where I increase the pointer address "p++;" IAR gives me the following error.
The stack pointer for stack 'CSTACK' (currently 0x...) is outside the stack range (0x.. to 0x..).
Any Ideas?
The error about CSTACK is fairly common and can be caused by a number of things.
What the error means:
This error is based on a relatively simple model of the micro's memory. IAR only knows about CSTACK as defined in the linker script file (icf file). While debugging, C-SPY is monitoring the stack pointer on whatever architecture you are using (for ARM, this is SP / R13). If it sees that the address in the stack pointer is not pointing into the area defined in the linker file as the CSTACK section, then it will produce this warning for you.
What could be causing it that is not an error:
There are a few things that can cause this without being alarming.
If you are using an OS or scheduler that maintains separate stacks for tasks, the stack pointer will point to the current task's stack at any given time. This is probably the most common reason for seeing the warning: Your running task isn't using the CSTACK section for its stack, and instead using either a static array declared in your code, or a chunk of memory from the heap. In this case, you can ignore the warning, but keep in mind that you will need to rely on your OS/scheduler or application code to monitor for any stack overflows if you need that checking.
Depending on the architecture, a separate stack may be used for interrupts. If you have halted execution in an interrupt and you're on one of these architectures, IAR may throw the warning here as well, for the same reason as above: You are running code that specifically is not using CSTACK as its stack. C-SPY doesn't know where the stack should be at this point, and thus your pointer is "invalid". Also like above, you can't rely on the debugger for stack monitoring in this case. You will need to add your own checks if you need this validated.
It could be an actual error:
Now, in terms of this error being appropriate: If the above cases don't apply to you, then it is possible that you have a stack overflow in your code. If you are using a new enough version of the IAR tools, they should be able to perform static analysis and let you know what your worst-case stack depth is. This isn't 100% accurate, and if you use function pointers or recursion (don't use recursion on an embedded system), the tool will barf and ignore those cases (which could be your real worst case).
If this could be a real stack overflow, then you can try the following, but do not just do this as a bandaid. This is not a proper fix, just a test to see if it is an overflow. In your project options, under linker, you can edit your linker settings (you can also do this by editing the icf file directly) to increase your CSTACK size. If you increase it dramatically (double, triple, quadruple) and your issue disappears, then it is likely that your stack is too small. You can check the stack depth analysis against the value here and what value worked as a sanity check.
If you dramatically increase the size of CSTACK and you still see the error, then there are a few possibilities that could still be bad things. If you have written any assembly code and your architecture allows for the stack pointer to be a general purpose register (i.e. ARM), then this is bad. One should follow the architecture's conventions, even if it lets you do otherwise. You also may not have proper startup code. On most architectures, you will need to configure the stack yourself. IAR should be using startup code by default that does this, but if you've overridden it with your own, then there could be a bug in setting up the stack.
Causes for a stack overflow
Recursion, if you're using it, and if not well bounded can easily fill up your stack. If you're using it, you'll have to use a combination of the stack depth analysis tool and manual analysis to figure out how much stack space you need.
Large buffers in function scope that are not static will end up on the stack. If you don't need to be reentrant, these should probably be static. These will properly be accounted for in IAR's stack analysis.
alloca will dynamically allocate memory from the stack. If you're using this, you may need to take that into account in the stack analysis. It is unlikely that IAR's tool will take into account memory allocated at runtime from the stack, since the size of the allocation can't be determined at compile time.