[ISIS] nonsense stack overflow error 16F876A

[T3STY]

Due to the very low memory on 16F84, I have switched to the PIC 16F876 (A). I managed to write 70% of the program, but right when I was writing the most important function I've run into a very nonsense stack overflow error in ISIS.

The error happens in the function Esposizione() with the code after line 309. On line 310 I have a function call which is:
LCD_WriteString("Esposizione\ncompletata");

What happens here is, if I write...
LCD_WriteString("Esposizione\ncompl");
...ISIS will go ahead just fine.
If I use any longer text or if I make any other function call after this function, ISIS will complain different either by running the program its way (only an arrow displayed and nothing works) or it will throw this error:

[PIC16 CORE] PC=0X0370. Stack overflow executing CALL instruction.

The very strange thing is that the stack overflow does not occur with functions calling other functions inside (like LCD_WriteString() which calls LCD_Write() inside), but with functions going one next the other in the code, which should trigger a PUSH on function call and a POP on function return. This way, the PC should never full fill the stack levels and I should be able to make even 1000 function calls one next the other. I have counted the function calls and I should have not more than 4 stack levels at this point (main() -> Esposizione() -> LCD_WriteString() -> LCD_write() ), and the PIC offers 8 stack levels. Obviously though, something doesn't fit the circumstances, and I'm unable to determine what. Or I may be wrong about function calls and stack levels...

I'm attaching here the whole MPLAB/HiTech PICC project and the ISIS simulation project. I'm sorry I didn't have time to comment the main.c file in english, but the code is a lot self-explainable. If you don't understand anything just ask me.
Oh, almost forgot... the code compiles just fine in MPLAB. There are a few warnings about char variables converted to char pointers, but they're not critical and won't stop the compilation process.

Thanks in advance to anyone willing to help me.

p.s. fast user guide for the program simulation in ISIS (if working)
On startup the display shows a menu. Use the DEC and INC buttons to move the arrow Down/Up. Use SEL to select the menu item.
The function causing issues, Esposizione(), is called on the first item in the menu, "AVVIA ESPOSIZ.". When the program runs the wrong way you should only see an arrow on the first char of the display, but you'll be unable to do anything.
p.p.s. In case you need to translate, Google translate seems to work fine for most of the sentences.

 

[betwixt]

I'm curious why you switched from an old 16F84 to an old 16F876A which has the same stack limitation. For 'upgrading' older programs using 16F84 and 16F628A I suggest looking at the 16F1847 which is exactly pin compatible but has twice the stack space and much more RAM and program memory. If you can use the internal clock, it also reduces component count by eliminating the timing components and it has more usable pins where the timing parts used to be.

Brian.

 

[FvM]

To reproduce the problem and understand if it's actually a"nonsense stack overflow" or regular behaviour, the *.cof file would be needed for the simulation.

 

[T3STY]

My switch is not because I needed more powerful PIC, I was just looking for more program space on the PIC. 16F84 has only 1024 words while 876 has 8192 words, just enough to store the whole program. I was looking at 628 too, but I had already own an 876, so I didn't actually consider buying another PIC if not needed. Thanks for the advice though

So, I am attaching here the .cof file with the build having the full sentence on line 310: LCD_WriteString("Esposizione\ncompletata!");. I am including the compiled .hex too. In ISIS, this build only shows an arrow on the display and nothing works.
I saw there are more files in the project directory, so I am attaching a full MPLAB session with the compiled code and all the output files. I hope they come in handy for you. Precisely, how will you use the .cof file to analyze what happens?

 

[FvM]

In ISIS, this build only shows an arrow on the display and nothing works.

I think it won't work in real hardware either. I'm not using HI-TECH C and not familiar with it's details of string handling. But as far as I understand, you are using wrong string pointer types, e.g. in char VisualizzaMenu(char menu[], char righe). menu must have a const storage class attribute to be processed correctly by the compiler. By tracing code execution in debugger (that's what the *.cof file is good for), you can see that the high byte of the string table address gets lost when dereferencing menu[sel], resulting in a jump to an incorrect code address.

String handling is generally difficult with all 8-Bit PIC compilers, but I presume the HI-TECH manuals is explaining the point. The said problem makes it impossible to check for a "nonsense stack overflow", but I guess it's a phantom bug caused by the string pointer code error or similar.

 

[T3STY]

Your explaining left me without any words, FvM!

I have read the HiTech manual about char and const char arrays, but they only say the obvious things I already know (how to work with const char arrays, read-only, cannot write to will throw a compiler error ect.). So I did the only easy and obvious thing I should have done since the beginning: use the same data type parameter as the data I'll be using in function VisualizzaMenu(). I have now converted the menu parameter to const char * menu which will still keep the strings array in program memory (instead of RAM) and I'll be accessing that data through a pointer.
The very same code that wasn't working before, now works flawlessly, without not even a warning from the compiler!

Thank you very very much FvM (I'm sorry, I can't remember your real name), and thank you Brian too!