'Help with EE writes in 16C84'
|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.
WRITE_EE MACRO ADR, DAT
Write_EEProm: PAGE1 ;Macro, move to page 1
Wait_EEProm: btfss EECON1-0x80,EEIF
PAGE0 ;Macro, back to page 0
I would appreciate any suggestions you could offer.
Get Your Private, Free Email at http://www.hotmail.com
On Wed, 13 Aug 1997 10:22:19 PDT Shane Buckham <HOTMAIL.COM> goweed
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.
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.
> 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
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
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- New search...