Searching \ for 'Help with EE writes in 16C84' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'Help with EE writes in 16C84'.

Truncated match.
PICList Thread
'Help with EE writes in 16C84'
1997\08\13@133317 by Shane Buckham

picon face
I've been having problems programming the internal EE area on the 16C84.
My code follows the sequence 0xaa, 0x55 etc as described in the data
book.  I'm using a picmaster emulator system.

When using the emulator it all works fine, the data is stored and
retrieved as would be expected.  When I burn the chip it fails to work.
I can easily tell if the programmed values are within the correct range
from the response of the target application.
I also use a Universal Xeltec programmer, with this I can pre-program
values into the EE that I know are in the correct range.  When I do this
it all works fine.  That is the chip is reading the values out of the
eeprom properly.  When I let it write the new values they are random in
value but written over the correct address range, the rest stay zero.

Originally I was using looping until the complete flag had come up.
I've also tried simply waiting the required delay but I still get
incorrect values.  Also tried different chips to see if the ee area on
the chip itself was at fault, unlikely I feel, no luck there either all
three chips behaved the same.

Here is a portion of the code in two parts macro and eewrite subroutine.

{macro write_ee}


                       movlw           ADR
                       movwf           EEADR
                       movf            DAT,W
                       movwf           EEDATA
                       call            Write_EEProm


{Subroutine Write_EEprom}

Write_EEProm:          PAGE1                    ;Macro, move to page 1
                      bcf     EECON1-0x80,WRERR
                      bcf     EECON1-0x80,EEIF
                      movlw   0x55
                      movwf   EECON2-0x80
                      movlw   0xAA
                      movwf   EECON2-0x80
                      bsf     EECON1-0x80,WR

Wait_EEProm:           btfss   EECON1-0x80,EEIF
                      goto    Wait_EEProm
                      bcf     EECON1-0x80,WREN
                      PAGE0                    ;Macro, back to page 0

I would appreciate any suggestions you could offer.

Many Thanks



Get Your Private, Free Email at

1997\08\13@145100 by Mike Keitz

picon face
On Wed, 13 Aug 1997 10:22:19 PDT Shane Buckham <.....goweedKILLspamspam@spam@HOTMAIL.COM>
{Quote hidden}

You need to have WREN set before attempting to set WR (and before the 55,
aa stuff) in the write routine.  Hardware doesn't set or clear WREN
except to clear it on a reset.   I have had good results ignoring the
WRERR and EEIF bits and polling the WR bit.  It will stick at 1 until the
write completes.  While waiting, be sure to clear the WDT if it is set up
for a short time.  The WRERR bit is only of relevance if you want to be
able to recover from a reset while a write was in progress.

If you have an interrupt that reads the EEPROM, it must be disabled while
a write is in progress.

Once you get it working, you can save a code word everytime you reuse
WRITE_EE by moving the movwf EEDATA into the Write_EEProm subroutine.

1997\08\13@145921 by Mike Keitz

picon face
On Wed, 13 Aug 1997 14:55:20 -0400 mkeitz writes:

>If you have an interrupt that reads the EEPROM, it must be disabled
>while a write is in progress.

And if you have any interrupts at all, they have to be disabled while
doing the write 55, write aa, set WR sequence, since if this sequence is
disrupted it won't write.

1997\08\13@152150 by John Payson

picon face
> If you have an interrupt that reads the EEPROM, it must be disabled while
> a write is in progress.

In the Atmel vs PIC comparison table, once of the PIC's supposed advantages
is that it can access the EEPROM even while it is being written.  This seems
unlike what I'd expect of a normal EEPROM device, but seems to be Microchip's
claim.  Does anyone know if any/all of the 16x84's permit this and under what

Also, re that table, I think Microchip makes some good points but some of the
complaints about the AVR are nonsensical.  For example, claiming that context
switch time is 128 cycles because of the need to save/restore all 32 registers
is ridiculous; odds are very good most ISR's will only need a handful of reg-
isters if that, and (esp. if programming in .ASM) they can be left unused in
the main program.  The PIC only has W, FSR, PCLATH, and STATUS to worry about,
but those (except for maybe FSR and--on the small devices--PCLATH) will need
to be saved/restored with just about any ISR.

Further, while having the stack pointer mapped in I/O makes SP manipulation
slower, there isn't the risk of corruption that Microchip suggests; while an
ISR will change the stack pointer during its execution, any non-terminal ISR
will always leave the stack pointer as it was on entry.  Thus, if I code [in

       load    R0,SP
       sub     R0,#9
       store   R0,SP

An interrupt may occur at the old or new stack-pointer value, and R0 may or
may not have been loaded from the stack pointer, but it won't matter; unless
the interrupt routine changes the SP without changing it back (in which case
it would be hard for it to return anyway) the ReadModWrite process will work
just fine.

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...