Andy wrote:
> There's no guarantee that the real chip and the PICMASTER are failing
> for the same reason... Have you tried burning a real chip with the
> "here: goto here" code?

Yes, and that worked fine.

>
> How do you know that the real chip ISN'T waking up?  Are you watching
> the OSCOUT pin to see if the clock starts up, or is there some other
> external indication that the ISR is being executed?

It wasn't on the first try early yesterday.  But now it is working!
The only change from before (I Think) is that I now re-set the RBIF
in the ISR.  ??!??

I guess the real fix was in setting up the ISR correctly, but the
fact that is was repaired was masked by the fact that the PICMASTER
will NOT wake up from sleep.  The new code with real sleep worked
first time on the real chip.

> Is there a chance that the instruction right after the "SLEEP" is
> screwing you up?  Remember that that instruction is executed before
> the ISR is called.

Yup, I have two nops after the sleep.  That's important.

>
> By the way, the PICMASTER does have some problems waking from sleep,
> so it's a good idea to use a conditional-assembly switch to replace
> "SLEEP" instructions with either infinite loops or -- when you're
> using the watchdog timer to wake the PIC -- delay routines.

Yes, that was what I was doing to test.  That worked from day one
under emulation.

Andy, Robert, Martin, Matt, Thanks for the ideas.  I will post again
when I run a delta on two codes and solve the mystery of which change
fixed it (I love version control software!).

Thanks,

Barry.
------------
Barry King, KA1NLH
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the accumulated (PIC) wisdom of the ages at:
PIC/PICList FAQ: http://www.piclist.org