Stack overflow ??

[noyz]

Hi,
I have PIC 18F8527 and it seems that when i use a boolean variable
it doesn't work as it should.
I set it true, but then it sets itself false.
Before this, I had a piece of code in a serial read function, and when I moved it to main, wow it works.

My question is
how does stack overflow react, how can i see when it appears.
How many levels does a PIC have ?
I found out that 18f8527 has 31.
It shouldn't overflow at 9.
Or that is an error ?
What else can make my variable go wrong ?
Pointers, int1 / booleans ? (because i have a lot of booleans .. not array, just boolean)
Struct with booleans ?
Struct with int8 ?

My lst file says :

ROM used: 13990 bytes (28%)
Largest free fragment is 35162
RAM used: 918 (23%) at main() level
992 (25%) worst case
Stack: 9 locations

[Ttelmah]

Not stack overflow, unless you are doing something internally in a function with you own assembler, which the compiler does not know about.

Remember, unlike chips like the Intel 80xxx, the PIC _does not_ have a 'variable stack'. It _only_ has a call address stack. Stack overflow will simply result in code going where it shouldn't. Set the STVREN fuse, and a stack overflow will reset the processor.

Your problem is much more likely to be 'memory bounds'. Multiple things here:
1) Remember the PIC does not have any form of hardware memory management. If (for example), you declare an array as int8 fred[10];, and then write to index 10 in this, the chip and compiler will not complain, but you _will_ have corrupted the next variable in memory...
2) Same applies (but even worse), if using pointer functions.
3) Remember variables are only 'static' in a function, if declared as so. If (for instance), a function returns a pointer to one of it's local variables, this variable _may well not exist_ as soon as the function exits.
4) Remember if you declare arrays to hold 'strings', that you need to leave space for the null terminator. A four character 'string', requires _five_ characters of storage - common error, and will result in other variables being destroyed.
5) Declaring a 'pointer', does not create any memory area for it to point 'to'. You need to do this yourself separately.

Your problem is almost certainly basic 'memory usage', not the stack.

Best Wishes

[noyz]

Thanks a lot for response.
I do believe that i have something like v[10] and then try to set v[10]
usually in java or in c++ you get an array out of index.
I'll take a look and see about everything else you said about.
Thanks.
This is a very useful answer.

[newguy]

There is a memory map file generated by the compiler and you should be able to look up the variable that's being corrupted and you'll see what's around it in memory. Should make finding what's causing the corruption a bit easier.