Olin Lathrop wrote:
>> Since you insist that my analysis was "rediculous" (sic), then
>> perhaps you can explain how the nop affected things, it was only a
>> nop after all.  At this point the only explanation that I can
>> imagine is that the length of the routines was the critical issue.
>
> If you're really really sure the interrupt routine saves/restores
> things properly, then location of code is the next thing to look at.

I was using a 16F628 so everyting was on one code page.  ISR was saving
W, STATUS, FSR and PCLATH for good measure.  Is there anything else that
could potentially get me?

> So, what constructs are sensitive to the location in program memory?
> Paging and all manipulation of PCL should be looked at carefully.

Oh I did.

> Also, if it's repeatable you should be able to single step thru it
> and see what's happening.  Does the forground code run correctly if
> you disable interrupts?

Without the ISR running, the foreground code wouldn't do anything but
loop, as it was waiting for the ISR to fill in a RAM location.  And
since the ISR was hit repeatedly so quickly by an external interrupt, it
would have been impossible to simulate with what I have available.  I
even thought that since I had two interrupt sources, that maybe somehow
I was receiving another while the first was being serviced, but that
can't happen unless I reenable GIE, right?  I really wish that I had
kept the "freaky" code, as it was quite perplexing, but I have run so
many things thru my feeble mind since then that I can't recall the exact
specifics of it.  I honestly spent quite some time scratching my head
(not that unusual ;-) and using the scope to monitor things before
resorting to trying the nop thing.  It's just that as the project
developed, I completely changed the way that everything worked.

It was when I was doing early fiddling with the I/R remote control
stuff.  Since the capture was new to me, I was doing analysis to make
sure that the ISR would stay synched to the data and decode it
correctly.  I could press a button and sometimes get the correct info,
but often it would decode it incorrectly.  By just adding a single nop,
it would work perfectly every time.  The main level was in a really
tight loop looking at a RAM variable, waiting for it to become non-zero
by the ISR filling it in.  It would then print it to an LCD, and then
clear the RAM location, and go back into the tight loop.  I thought that
maybe jitter in entering the ISR was somehow affecting things, but that
seems very unlikely as the scope showed that bit sampling was occuring
on the trailing edge of the pulses.  Sometimes, I really wish I could
afford a logic analyzer and an ICE debugger.  :-(  But on the machines
I've coded on in the past, I never had the luxury of even a simulator.

BTW, it all works flawlessly now and has been running for several days
without any hint of a problem.

Believe me, I hated to move on without completely solving the mystery,
as I well know how these things can come back to haunt you.  When I get
some time, I will try and duplicate the scenario.  Who knows, maybe I
found something akin to the famous GIE bit flicking issue, but then
again probably not.

When Justin posted his similar symptom, I was compelled to report my
experience as it seemed quite coincidental.  I certainly didn't figure
that he wasn't saving any of his context.  :-/

michael brown

"In the land of the blind, he who has one eye is king"

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads