-
PIC16F917 stack issues
Hi
I have programmed a 16F917 with PBP 2.46 It is an extensive application generating around 4058 words. I use assembly level interrupts to multiplex 8 seven segment displays. Besides this, I handle a dot matrix printer to print logs. I2C handles an external 24C512 and a PCF8583 RTC.
There is a lot of code which nests upto 6 levels deep (if I dig into the listing file). Of this, the I2Cread and write itself nests to 3 levels deep. My code nests upto 3 levels deep. 1 level is for display refresh interrupt and occurs periodically.
QUESTION:
Is there any way I can know the subroutine nesting levels in the PBP listing? Is there any utility that can tell me this info?
WHY:
I am facing problems in the working of the code where I feel the subroutine has nested to level 9(which overwrites stack level 0). When un-nesting from the subroutines, I hit the level 0 routine which puts me in a hung state in the call to the subroutine that nested at level 9(0).
thanks for any inputs
Jerson
-
-
Thanks Mr E
I was searching this same forum with different words and found the very same article that you referred. Thanks very much and 3 Cheers to Darrell T. I think he has already encountered the issues I am facing now. In fact, I am already using the GetAddress macro in my programs. Something new to try.
Still, I would like to know the nesting level without having to dig into the listing file. You know - a year from today, if I have to modify the prog, I may break something. Thats why.
Thanks Mr E and DT
Jerson
-
the easiest solution would be to increment a variable before each gosub, and decrement before each return. Sending result to a LCD, RS232 or use an ICD to monitor it.
sure there's some other way...
-
Somehow, an interesting finding here for those using the MCS ICD.
When you hit 'ICD Compile and program' button (or CTRL+F10), it create a variable named DEBUG_STACK which hold the value/actual level of the stack.
NOW, to make things simple, just add those lines
Code:
@STACK_LEVEL = DEBUG_STACK
STACK_LEVEL VAR BYTE EXT
And look what happen to your STACK_LEVEL variable in the ICD window while jumping here and there with gosubs.
i used that one...
Code:
DEFINE LOADER_USED 1
DEFINE OSC 20
@STACK_LEVEL = DEBUG_STACK
STACK_LEVEL VAR BYTE EXT
START:
PAUSE 1000
GOSUB LEVEL1
GOTO START
LEVEL1:
PAUSE 1000
gosub LEVEL2
RETURN
LEVEL2:
PAUSE 1000
GOSUB LEVEL3
RETURN
LEVEL3:
PAUSE 1000
gosub level4
RETURN
LEVEL4:
PAUSE 1000
RETURN
WOOOOHOOOO! Don't break my bubble ;) to me it's a nice finding... maybe usefull one day or another. Down side... it won't work unless you use the ICD... Darrel's stuff have a BIG advantage as you just need to read the StackPTR byte variable.
-
Hi Steve
I was wondering what is this ICD thing you talk about. Is it a part of Microchip MPASM suite or MCS electronics?
Anyhow, the latest update on my problem - I have it nailed. It wasnt the stack overflow after all. I had a case of data corruption in the event log. This particular case (case else) was not being handled leading to a program crash.
However, come to think of it, I appreciate your helping me and discovering something in the meanwhile. How nice would it be if the Melabs team could do something in the compiler/manual to show the stack nesting level of their inbuilt functions? I think the documentation should mention this as it is a very important aspect when using Pics with 4 level stack.
Jerson
-
I refered to the Mecanique ICD which come with MicroCode Studio Plus...
short tutorial on Bruce's website.
http://rentron.com/PicBasic/MCS_X3.htm
The full Version of MicroCode Studio really worth it's price. I really love the Bootloader. I don't often use the ICD, but found something interesting with this thread.
