Searching \ for '[PIC]: Sub returning, and jumping to middle of int' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Sub returning, and jumping to middle of int'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Sub returning, and jumping to middle of int'
2003\02\27@045716 by Tim

flavicon
face
Hello all once again,

        OK... this is a tough one.
        I have a PIC project I'm working on, using a PIC16F873, and the
code is doing some amusing stuff, that I can't seem to track down for
the life of me. At the point of failure, the code is writing some
variables to EEPROM, and returning to the calling subroutine.. thing is,
when the sub that’s saving the values returns, its jumping to part of
the interrupt vector. Almost in the middle of it in fact. The place its
jumping to seems to have no specific ness to it, its just jumping a
random (but same each time) part of the int vector. Once it jumps to
that location, it runs through the interrupt routine like it would as if
it was actually going there due to an int, and when it hits the RETFI,
it jumps *back* to the same location it jumped to originally in the
vector. The same off the wall place, and it does this indefinitely, thus
the PIC stops responding...

       I'm tracking this via a MPLAB compatible ICD, and since the ICD
cant track interrupts I know its not going there due to a normal
interrupt (I have timer0 set so it hits the interrupt vector constantly
as matter of coarse...). I've pored over the code countless times, but
can't find anything wrong. I am using the RS232 code by Tony Kübek. I
put a #ifdef around the interrupt code, any calls to the code in the
rest of the program, and around the include of the rs232 code. If I
undef the define, basically no rs232 code included, I don’t hit the jump
to the interrupt area. A step through of the program shows everything
taking place like it should.
       I don’t believe this to be caused by the serial routines due to
the fact I have used them on an '877 with no problems, and because I
originally had a set of routines that were being called from the
interrupt vector that were causing a very similar problem. I didn’t have
the ICD at that time so I don’t know if what was happening then is the
same now, but the symptoms were exactly the same, the PIC would stop
responding after the same subroutine returned. I resolved that problem
by placing most of the code that was called from the interrupt vector,
into the interrupt vector itself. Don’t ask me why that fixed it, but it
did. Again I had no ICD at that time so I don’t know exactly what was
going on. Its not a problem with the PIC, as this particular problem was
happening on both a '872 and the '873A.

       If I step through it, or let it run then halt it, the only
registers that appear to be changing are timer0's counter and pcl,
nothing else is moving.
I cant find anything that appears to be horribly wrong.
       If anyone out there would be willing to poor over the code and
see if they can point anything out that’s wrong I'd appreciate it. I
would prefer someone who could contact me via AIM or something so I
could run tests and report back to them in real time what's going on.
This thing is driving me up a wall, and I cant find anything that’s
throwing up a red flag.. I just don’t get how its jumping to a spot in
the interrupt vector, the same spot each time, for no apparent reason.

       All the code is on the first page of program memory, so its not
a paging problem... I'm out of ideas!

Thanks again,
Tim Thompson

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@062556 by Jinx

face picon face
> The place its jumping to seems to have no specificness to it,
> it's just jumping a random (but same each time) part of the int
> vector

A big hairy clue ?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@071850 by Alan B. Pearce

face picon face
>         I have a PIC project I'm working on, using a PIC16F873, and the
>code is doing some amusing stuff, that I can't seem to track down for
>the life of me. At the point of failure, the code is writing some
>variables to EEPROM, and returning to the calling subroutine.. thing is,
>when the sub that’s saving the values returns, its jumping to part of
>the interrupt vector. Almost in the middle of it in fact. The place its
>jumping to seems to have no specific ness to it, its just jumping a
>random (but same each time) part of the int vector. Once it jumps to
>that location, it runs through the interrupt routine like it would as if
>it was actually going there due to an int, and when it hits the RETFI,
>it jumps *back* to the same location it jumped to originally in the
>vector. The same off the wall place, and it does this indefinitely, thus
>the PIC stops responding...


two possibilities.
1. Somewhere you call a routine, but jump back to where you came from, so
you do not pop the return address from the stack - symptoms you give suggest
this happens inside interrupt routine at the point you keep returning to.

2. You are using more than 8 levels of stack, including the interrupt
routine, again causing the stack to wrap around.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@081943 by Tim

flavicon
face
Thing is, nothing in the interrupt routine have anything to do with the
code that's causing the problem. They have no relation to each other in
anyway.

Second, how can I eaisly tell how many levels deep I am going into the
stack?

-Tim

{Original Message removed}

2003\02\27@090411 by Dennis J. Murray

flavicon
face
FWIW:  I'd look HARD at a stack overflow problem, Tim!!  You're exhibiting
classic symptoms of stack overflow (according to your post, removing a
"called" routine made the problem "go away").

Although it's not a panacea to all the world's ills, I develop and document
my programs in "top down" structure and that makes it easy to see how deep
my deepest calls go.  If you haven't done that, you might be forced to bring
the source into an editor and search for all "CALL"s and try to figure out
how many can be outstanding at once.

Be aware!  If it IS a stack problem, you MAY be more than one level too deep
in some paths thru the program - don't stop looking if you find the 9th
level and fix it - there may be another just waiting to bite you!

Good luck!
Dennis

{Original Message removed}

2003\02\27@102136 by Olin Lathrop

face picon face
> At the point of failure, the code is writing some
> variables to EEPROM, and returning to the calling subroutine.. thing is,
> when the sub that’s saving the values returns, its jumping to part of
> the interrupt vector. Almost in the middle of it in fact. The place its
> jumping to seems to have no specific ness to it, its just jumping a
> random (but same each time) part of the int vector. Once it jumps to
> that location, it runs through the interrupt routine like it would as if
> it was actually going there due to an int, and when it hits the RETFI,
> it jumps *back* to the same location it jumped to originally in the
> vector. The same off the wall place, and it does this indefinitely, thus
> the PIC stops responding...

A RETURN and RETFIE always jump to the location on the stack.  Therefore
the real question is how did the location in the middle of your interrupt
routine end up in all 8 stack locations?  Take a look at the stack with
the ICD.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@115939 by Alan B. Pearce

face picon face
>Thing is, nothing in the interrupt routine have anything to do
>with the code that's causing the problem. They have no relation
>to each other in anyway.

You have just fallen into the big bear trap of any sort of computing. The
fact that this code apparently has nothing to do with where you think the
code is failing is the point. At some stage in the interrupt routine you did
a call without a return, or a return without a call. Somehow the address of
the interrupt routine is left on the subroutine stack.

>Second, how can I eaisly tell how many levels deep I am going
>into the stack?

Use the MPLAB simulator, and set the stack depth error detection on is
probably a good start point. Also be aware that you can set up a stimulus
file to trigger the interrupt at any point you want.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@120916 by Alan B. Pearce

face picon face
>Thing is, nothing in the interrupt routine have anything to do
>with the code that's causing the problem. They have no relation
>to each other in anyway.

>Second, how can I eaisly tell how many levels deep I am going
>into the stack?

Of course on thinking about it there is a second possible problem, you may
be suffering from stack underflow, and the stack happens to have a value
that leaps into the middle of the interrupt routine, because that is how it
sets itself up at power on. If you have only (say) 3 levels used but do 4
returns, what happens - possibly exactly what you are seeing. Somewhere
along the line your calls and returns (possibly including interrupt routine)
is out of whack.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@121224 by Bob Barr

flavicon
face
On Thu, 27 Feb 2003 09:01:38 -0500, "Dennis J. Murray" wrote:

>FWIW:  I'd look HARD at a stack overflow problem, Tim!!  You're exhibiting
>classic symptoms of stack overflow (according to your post, removing a
>"called" routine made the problem "go away").
>

IIRC, the ICD requires 1 stack level for its operation which would
increase the likelihood of this occurring.


Regards, Bob

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\28@035158 by Tim

flavicon
face
Its happening anyway, ICD or not, so it must be going pretty damn deep

-----Original Message-----
From: pic microcontroller discussion list
[spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU] On Behalf Of Bob Barr
Sent: Thursday, February 27, 2003 9:02 AM
To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Subject: Re: [PIC]: Sub returning, and jumping to middle of int
vector...?

On Thu, 27 Feb 2003 09:01:38 -0500, "Dennis J. Murray" wrote:

>FWIW:  I'd look HARD at a stack overflow problem, Tim!!  You're
exhibiting
>classic symptoms of stack overflow (according to your post, removing a
>"called" routine made the problem "go away").
>

IIRC, the ICD requires 1 stack level for its operation which would
increase the likelihood of this occurring.


Regards, Bob

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\28@035208 by Tim

flavicon
face
For thoes interested, I was able to avoid the lockup by adding a label
after the breaking routine and having said routine goto that label
instead of returning. Feels kinda kludgy to me, but are workarounds like
this common place? If so, I don't feel so bad about doing it

Thanks,
Tim

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\28@041115 by Peter L. Peres

picon face
Your problem sounds like a stack overrun to me.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\28@041145 by Peter L. Peres

picon face
Cuont the maximum depth of subroutine nesting in your program, and add the
depth of nesting +1 in all isrs that can be concurrent. The sum must be
smaller or equal to the stack you have.

Peter

On Thu, 27 Feb 2003, Tim wrote:

*>Second, how can I eaisly tell how many levels deep I am going into the
*>stack?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\28@041743 by Jinx

face picon face
> Feels kinda kludgy to me, but are workarounds like this
> common place? If so, I don't feel so bad about doing it

Probably more common than people would 'fess up to ;-)

There's always a feeling of unfinished business when you
kludge. Does the little guy who has your ear have a white
suit and a halo or a red suit and horns ?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\28@073740 by Olin Lathrop

face picon face
> For thoes interested, I was able to avoid the lockup by adding a label
> after the breaking routine and having said routine goto that label
> instead of returning. Feels kinda kludgy to me, but are workarounds like
> this common place?

Not in my code!

> If so, I don't feel so bad about doing it

You should though.  Something is still wrong and all you've done is
covered up the one hint it's giving you.  I strongly advise to get to the
bottom of this, then fix it right.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\28@133059 by Peter L. Peres

picon face
On Fri, 28 Feb 2003, Tim wrote:

*>For thoes interested, I was able to avoid the lockup by adding a label
*>after the breaking routine and having said routine goto that label
*>instead of returning. Feels kinda kludgy to me, but are workarounds like
*>this common place? If so, I don't feel so bad about doing it

When you are desperately short on stack they are.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


'[PIC]: Sub returning, and jumping to middle of int'
2003\03\03@180802 by Dennis J. Murray
flavicon
face
I disagree, Peter!!  Not much is worse than a 12C509's stack - it's only 2
levels deep!!  Back a few years ago, I had quite a few projects to do using
the '509, and I've NEVER had a kludge like that!!  You just have to change
your programming style, NOT ignore a problem when you find it "goes away"
when you jump to an address rather than issue a RETURN!!

I really think HELL is going to be a place where you're required to write a
FORTH compiler on a '509!!!

Look for the error - if not, it's almost a guarantee that it'll bite you
someday!
Dennis

{Original Message removed}

2003\03\04@194803 by Peter L. Peres

picon face
On Mon, 3 Mar 2003, Dennis J. Murray wrote:

*>I really think HELL is going to be a place where you're required to write a
*>FORTH compiler on a '509!!!

ROFL. (I wrote a small interpreter that ran in 12C509/508 + external
eeprom - it was a clever programmable timer/thermostat combo). If you are
looking for a stack where there isn't one you will be looking for a long
time ... so stop looking and implement it as a 'flat' stackless data
structure. I remember it was fun getting the index pointer (FSR) to
address what *I* wanted and not what it wanted while jumping between
EEPROM contents and normal file registers used as accumulators and timers.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\03\05@085902 by Dennis J. Murray

flavicon
face
I can fully appreciate your efforts, Peter.  The '509 was frustrating to me
because I tend to write structured code wherever possible, and the '509's
stack was highly limiting (yes, it DOES have one - 2 levels worth).

I probably misunderstood your post, but I got the impression you feel the
'509 is stackless.  If so, then read page 1 of the 12C5xx manual (DS40139E).
Also, without a stack, the CALL and RETLW would be worthless.

If I did misunderstand your post, my apologies - just ignore my comments.

Dennis

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...