Well, here's how it turned out:

We have had this system running around the clock for quite a while.  During
the course of system development, we have many times turned off the "target
system", which also removes power from the ICD.  However, it didn't occur to
me to re-boot the host PC as a solution to this problem.  After posting to
the list last night, I turned EVERYTHING off and went home for the night in
a state of great frustration.  When I turned it all on this morning,
everything was back to normal.

I appreciate the helpful suggestions, I only wish I had thought of
re-booting the host before posting.  Still, there may be some general value
in the observation that there seems to be some sort of RAM image of the
target PIC held in the PC memory which can apparently get corrupted somehow
with very confusing results.

Once again. thanks to everyone for your time and attention.

Best regards,

        Foster

> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of adastra
> Sent: Wednesday, September 27, 2000 7:12 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: [PIC]: COMPLETELY PERPLEXED! (I usually think it's me, but...)
>
>
> I am writing a couple of thousand lines of code for 16c877 using the ICD.
> Well into the project, I have encountered some very strange problems
> involving data memory variables.  I have defined a list of them
> starting at
> 0x0020.  At some places in my program, I cannot seem to write to
> them, even
> though I THINK I have taken care with respect to the proper bank and page
> definitions.  For instance, in this case:
>
> calib   nop
>         banksel msg_nbr
>         movlw   .65             ;table address
>         movwf   msg_nbr
>         movwf   sp1
>
> The literal in w WILL be written to msg_nbr, but NOT to sp1.
>
> FWIW, msg_nbr is assembled at 0x0024 and sp1 is at 0x003D (using
> CBLOCK/ENDC.)  Curiously, if I reverse the placement of the
> variable names,
> the result reverses also.  That is, if sp1 assembles at 0x0024 and msg_nbr
> is assembled at 0x003D, the program fragment shown will write to
> sp1 but not
> to msg_nbr.  This seems to suggest that there is something wrong with the
> memory location itself, but I have swapped physical '877 devices
> and gotten
> the same result.
>
> The final blow came when I discovered, by single-stepping ICD, that
> sometimes even "BSF flags1,0" would not set the designated bit.
> (flags1 is
> assembled at 0x0020)
>
> I should add that all of this code is on page 0, (PCLATH is at
> 0x00) and the
> RP1:RP0 bits in STATUS say I am looking at data memory bank 0.
>
> Has anyone seen anything like this before?  I usually think its just my
> oversight (and it usually is,) but this time I'm not so sure.
>
> I am completely perplexed by this, and am simply stopped in my
> tracks.  I am
> hoping some of you brilliant and more experienced folk out there have a
> suggestion or two for me.
>
> Thanks once again for your invaluable assistance.
>
>         Foster
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST
>
>
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu