PIC16F917 stack issues

[Jerson]

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

[mister_e]

try this one...
http://www.pbpgroup.com/modules/wfse...p?articleid=14

[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

[mister_e]

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...

[mister_e]

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

@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...

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.

[Jerson]

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

[mister_e]

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.