16F913 mind of it's own

Using the simulator the program in question works sometimes and
sometimes doesn't. I am trying to isolate a couple of problems as a
last resort by placing an endless loop in the code (endhere. . . .
goto endhere). But it breaks out of that. I've turned off the
interrupts, they aren't used at all in the program. On the simulator
it will jump to incorrect places from a certain point. It has gone to
1700 lines in the editor, and only the last bit of code added has
shown this. The stack should not be causing this by overflowing, as in
this situation it isn't running more than one or two nested loops. All
the calls at this point have finished, and the routine is simply to go
back to an earlier point with a goto. But as I said, even placing an
endless loop won't keep the code in check. The WDT is off also.
I'm looking for a general answer so won't post the code. Please help!

<Sirhcyarguk@yahoo.co.uk> wrote in message 
news:1182700668.835359.267300@n2g2000hse.googlegroups.com...
> Using the simulator the program in question works sometimes and
> sometimes doesn't. I am trying to isolate a couple of problems as a
> last resort by placing an endless loop in the code (endhere. . . .
> goto endhere). But it breaks out of that. I've turned off the
> interrupts, they aren't used at all in the program. On the simulator
> it will jump to incorrect places from a certain point. It has gone to
> 1700 lines in the editor, and only the last bit of code added has
> shown this. The stack should not be causing this by overflowing, as in
> this situation it isn't running more than one or two nested loops. All
> the calls at this point have finished, and the routine is simply to go
> back to an earlier point with a goto. But as I said, even placing an
> endless loop won't keep the code in check. The WDT is off also.
> I'm looking for a general answer so won't post the code. Please help!
>
Could it be as simple as a spike on the reset line? 

<Sirhcyarguk@yahoo.co.uk> wrote in message 
news:1182700668.835359.267300@n2g2000hse.googlegroups.com...
> Using the simulator the program in question works sometimes and
> sometimes doesn't. I am trying to isolate a couple of problems as a
> last resort by placing an endless loop in the code (endhere. . . .
> goto endhere). But it breaks out of that. I've turned off the
> interrupts, they aren't used at all in the program. On the simulator
> it will jump to incorrect places from a certain point. It has gone to
> 1700 lines in the editor, and only the last bit of code added has
> shown this. The stack should not be causing this by overflowing, as in
> this situation it isn't running more than one or two nested loops. All
> the calls at this point have finished, and the routine is simply to go
> back to an earlier point with a goto. But as I said, even placing an
> endless loop won't keep the code in check. The WDT is off also.
> I'm looking for a general answer so won't post the code. Please help!

Going over a memory or page boundary ?
especially easy with look up tables.

Functions calling other functions more than 8 levels deep ?

Getting close to maximum program size ?

Sounds a software problem if you are getting errors
on the chip and in the simulator.

Alex

"Alex Gibson" <news@alxx.org> writes:
> <Sirhcyarguk@yahoo.co.uk> wrote
> > Using the simulator the program in question works sometimes and
> > sometimes doesn't. I am trying to isolate a couple of problems as a
> > last resort by placing an endless loop in the code (endhere. . . .
> > goto endhere). But it breaks out of that. I've turned off the
> > interrupts, they aren't used at all in the program. On the simulator
> > it will jump to incorrect places from a certain point. It has gone to
> > 1700 lines in the editor, and only the last bit of code added has
> > shown this. The stack should not be causing this by overflowing, as in
> > this situation it isn't running more than one or two nested loops. All
> > the calls at this point have finished, and the routine is simply to go
> > back to an earlier point with a goto. But as I said, even placing an
> > endless loop won't keep the code in check. The WDT is off also.
> > I'm looking for a general answer so won't post the code. Please help!
> 
> Going over a memory or page boundary ?
> especially easy with look up tables.
> 
> Functions calling other functions more than 8 levels deep ?
> 
> Getting close to maximum program size ?
> 
> Sounds a software problem if you are getting errors
> on the chip and in the simulator.

Writing over the return address?

"Everett M. Greene" <mojaveg@mojaveg.lsan.mdsg-pacwest.com> wrote in message 
news:20070625.799BFC0.6B1C@mojaveg.lsan.mdsg-pacwest.com...
> "Alex Gibson" <news@alxx.org> writes:
>> <Sirhcyarguk@yahoo.co.uk> wrote
>> > Using the simulator the program in question works sometimes and
>> > sometimes doesn't. I am trying to isolate a couple of problems as a
>> > last resort by placing an endless loop in the code (endhere. . . .
>> > goto endhere). But it breaks out of that. I've turned off the
>> > interrupts, they aren't used at all in the program. On the simulator
>> > it will jump to incorrect places from a certain point. It has gone to
>> > 1700 lines in the editor, and only the last bit of code added has
>> > shown this. The stack should not be causing this by overflowing, as in
>> > this situation it isn't running more than one or two nested loops. All
>> > the calls at this point have finished, and the routine is simply to go
>> > back to an earlier point with a goto. But as I said, even placing an
>> > endless loop won't keep the code in check. The WDT is off also.
>> > I'm looking for a general answer so won't post the code. Please help!
>>
>> Going over a memory or page boundary ?
>> especially easy with look up tables.
>>
>> Functions calling other functions more than 8 levels deep ?
>>
>> Getting close to maximum program size ?
>>
>> Sounds a software problem if you are getting errors
>> on the chip and in the simulator.
>
> Writing over the return address?

There are 2 ways to get out of the endless loop "endhere: goto endhere":
1. Resets:
    noise on reset pin or brownouts: Put scope on reset pin and on Vdd to 
check.  Momentary heavy loads on power can     pull Vdd low.
2. Interrupts:
    Interrupts enabled:  Some high level languages do unexpected things like 
enabling interrupts for internal functions.

Don