Hi Steve,

Thanx for the reply; I played around with the code a bit yesterday (and even
created my own test program - listed below).

>Are you sure this is where it's locked up?  How do you know if running
>on a real device?

No, I'm not sure that's where it's locked up.  Actually, from your comments
below, I suspect that it's not locked up in the polling loop.

>
>>
>> The Code is:
.
:
>>
>>   bcf    EECON1 & 0x07F, WREN  ;  Disable the EEPROM From Writing
>>   bcf    STATUS, RP0
>>   return
>>
>
>Assuming that your equates are all OK...

I've reviewed the produced code and all the values look okay.

>
>I can't see anything wrong with this code fragment except perhaps a
>(harmless) typo on the third last line.

Thanx for pointing out the Typo (I've fixed it in the snippet above).

>It could be an interrupt
>routine going haywire.  You enable interrupts prior to testing WR going
>low.  If the interrupt routine accidentally clears RP0, or assumes that
>RP0 is cleared and thus messes with the wrong registers, then you'll be
>in strife.

Yah.  Thanx for pointing that out.  I will change the code so that RP0 is
reset in the interrupt handler.  The interrupt handler itself changes values
in PORTA and PORTB to drive the LED displays.  So, there is a good chance
that this would get screwed up.

>It's a matter of taste, but I prefer to turn off WREN immediately after
>setting WR, especially if interrupts are enabled while waiting for
>write completion.  This will prevent accidental re-setting of WR which,
>although the manual doesn't say much about it, could extend the write
>cycle indefinitely.

Thanx for the hint.  I'll try that in my test code tonight.

>Trace it through to see why it is executing so quickly.  What precisely
>is it that is taking only one cycle: is the tight loop bailing out
>immediately?

Right now, I am just single stepping the code.  Is there any other way I
should be tracing what's happening?

>After resetting the device, does the EEPROM location read 0x55 or is it
>junk?

To test out the EEPROM write (ie make it very simple to understand what was
happening), I created the following code.  In terms of Hardware, I have
attached a 4.7K Resistor from Vdd to _MCLR with a momentarily on switch
pulling _MCLR to ground and a 4.7K Resistor from Vdd to RA0 with a
momentarily on switch pulling the pin to ground.  I put on 8 LED's with 220
Ohm Resistors to Vdd on all the PORTB bits to show what's going on.

 title "Test8 - Test Writing to the EEPROM."
;
;  This Program Reads the Value in EEPROM Adress 0, displays it on 8 LEDs,
;   waits for a button Press (at RA0) and then shows the value in EECON1 on
;   the LEDs.  This program is to help explain why I'm having trouble writing
;   the EEPROM.
  LIST P=16C84, R=DEC
  errorlevel 0,-305
  INCLUDE "d:\picstart\p16cxx.inc"

;  EEPROM Registers
Chk     EQU     0               ;  Check Value for Reading

 __CONFIG _CP_OFF & _XT_OSC & _PWRTE_ON & _WDT_OFF

  org    0

  clrf   PORTB                  ;  Set PORTB to All Output
  bsf    STATUS, RP0
  clrf   TRISB & 0x07F
  bcf    STATUS, RP0

  movlw  Chk                    ;  Read "Chk" in EEPROM
  movwf  EEADR
  bsf    STATUS, RP0
  bsf    EECON1 & 0x07F, RD
  bcf    STATUS, RP0
  movf   EEDATA, w

  xorlw  0x0FF                  ;  Display the Value in "Chk"
  movwf  PORTB
  xorlw  0x0FF

  btfsc  PORTA, 0               ;  Wait for Button Press to Continue
   goto  $ - 1

  addlw  1                      ;  Increment the Read Value

  bsf    STATUS, RP0            ;  #### - Changed to See if WREN Set Earlier
  bsf    EECON1 & 0x07F, WREN   ;   will Fix the Problem.
  bcf    STATUS, RP0
  movwf  EEDATA                 ;  Write the Incremented Value Back into the
  movlw  Chk                    ;   EEPROM
  movwf  EEADR
  bsf    STATUS, RP0
  movlw  0x055                  ;  Put in MChip Specified Code Sequence
  movwf  EECON2 & 0x07F
  movlw  0x0AA
  movwf  EECON2 & 0x07F
  bsf    EECON1 & 0x07F, WR
Loop                            ;  Display EECON1 Status
  movlw  0x0FF
  xorwf  EECON1 & 0x07F, w
  bcf    STATUS, RP0
  movwf  PORTB
  bsf    STATUS, RP0
  goto   Loop

  end

This program initially shows the value in "Chk" and then waits for a button
press to continue on with the write.  I put the Button on _MCLR to allow me
a quick reset and see what was actually written.

When I run this code in MPLAB, It works exactly as expected - except for how
quickly the EEPROM is written (at the "bsf STATUS, RP0" instruction, EECON1
changes to show that the write has completed by setting the EEIF and
resetting WR.  WREN is still set as well).  I have created a small stim file
which goes through two cycles to show that the EEPROM is getting written.

When I first ran the program on Hardware, along with WREN and EEIF being
set, I also got WRERR being set.  But, when I re-ran the program (ie hit
reset), the value I read from EEDATA was correct.

So I thought it was running okay despite the WRERR.

Now, when I turned off the power to the PIC and left it for a five minutes
and re-ran the program, I found that the program didn't have the Value in
EEPROM I was expecting (ie the last incremented value).  Re-reading the
Datasheets for the EEPROM (Chapter 7 of the 16C84 Datasheets), I see that
EEADR and EEDATA don't change on an error and I guess the charge is sticking
around inside the PIC for a few minutes (I did turn off the power, remove
the PIC from the proto-board and then put it back in and found that often
the value would still be in EEDATA - it really took five minutes for the
charge to dissapate).

Does anybody have any idea on what's causing the WRERR?  I'm running the PIC
at 1 MHz (it's a 4 MHz part) on a Protoboard.  It almost seems like I'm not
setting the PIC up properly for an EEPROM Write.

Thanx,

Myke
>
>

Do you ever feel like an XT Clone caught in the Pentium Pro Zone?