Searching \ for '[PIC] EEPROM Fun..' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/memory.htm?key=eeprom
Search entire site for: 'EEPROM Fun..'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] EEPROM Fun..'
2006\09\11@150325 by Steven Howes

picon face
Yes me again..

I am working on a little project with a PIC16f690, which involves reading/writing the data EEPROM. I have a chunk of code (shown below) That writes one byte, then loads the other into working and writes that.. the only thing is.. you only get the second. When you write it, the rest of the EEPROM is nuked. I have to say my EEPROM experience is limited (ie i have no idea what i am doing). I have read elsewhere that some of them have to be rewritten in chunks, rather than individual bytes, i cannot see anything in the datasheet saying this for the PIC... anyway... 'ere is my code

save
       movfw emt
       BANKSEL EEADR ;
       MOVWF EEDAT ;Data Memory Value to write
       movlw 0x0;        MOVF DATA_EE_ADDR, W;
       MOVWF EEADR ;Data Memory Address to write
       BANKSEL EECON1 ;
       BCF EECON1, EEPGD ;Point to DATA memory
       BSF EECON1, WREN ;Enable writes
       BCF INTCON, GIE ;Disable INTs.
       MOVLW 55h ;
       MOVWF EECON2 ;Write 55h
       MOVLW 0xAA ;
       MOVWF EECON2 ;Write AAh
       BSF EECON1, WR ;Set WR bit to begin write
       BCF EECON1, WREN ;Disable writes
       BANKSEL 0x00 ;Bank 0


       movfw emtinv
       BANKSEL EEADR ;
       MOVWF EEDAT ;Data Memory Value to write
       movlw 0x1;        MOVF DATA_EE_ADDR, W;
       MOVWF EEADR ;Data Memory Address to write
       BANKSEL EECON1 ;
       BCF EECON1, EEPGD ;Point to DATA memory
       BSF EECON1, WREN ;Enable writes
       BCF INTCON, GIE ;Disable INTs.
       MOVLW 55h ;
       MOVWF EECON2 ;Write 55h
       MOVLW 0xAA ;
       MOVWF EECON2 ;Write AAh
       BSF EECON1, WR ;Set WR bit to begin write
       BCF EECON1, WREN ;Disable writes
       BANKSEL 0x00 ;Bank 0

As you can see, its hbast*rdised from the data sheet.. The two registers i am saving to the eeprom are 'etm' and 'emtinv' saving them to 0x0 and 0x1 respectively. If it run it, the pull out the chip and put in my programmer and read the data off it.. only 0x1 has data in. If i add a third one after it.. only the third one is done. Is there some delay between consecutive writes? Thanks for any help, and for putting up with me (come on, you love me really).

Steve

2006\09\11@152843 by Maarten Hofman

face picon face
>
> add a third one after it.. only the third one is done. Is there some delay
> between consecutive writes? Thanks for any help, and for putting up with me
> (come on, you love me really).


Yes, generally you have to wait before the write is complete before starting
a second one. Also, you have to make sure there is enough voltage/current to
complete the write during that cycle. Note that the example code uses a
"SLEEP" operating with interrupt to wait, this has the advantage that the
power consumption of the rest of the chip is reduced during the write. If
you don't use the sleep, you will still need to check for the interrupt bit
(EEIF) to be set indicating that the write is finished. Usually you will
have to clear this bit manually afterwards.

Some people would also recommend reading the EEPROM after the write, to
check if the value has actually been written to it.

If your application isn't time critical, the best thing is to check for EEIF
after your write, and wait for the write to complete that way. If it is time
critical, you could postpone this wait until before you write, thereby
allowing the write to continue while the rest of your program executes.

Note that while you are writing, a read from the area you are writing to
might not return the correct value. Most PICmicros will return the correct
contents for all other memory locations though. An exception are certain
revisions of PIC16F628A (and possibly 627A and 648A), which have a bug that
will cause the write to fail in case you read the EEPROM at the same time.
Possibly there are other PICmicros that have the same problem. Of course,
this can be prevented by waiting with reading until the write is finished.

Greetings,
Maarten Hofman.

2006\09\11@154806 by Steve Smith

flavicon
face
You need to check that the first byte is finished before writing any
more.... see note in code it should work then
Steve..

{Original Message removed}

2006\09\11@161707 by Steven Howes

picon face
Thanks I will add the checking loop tomorrow (working from home, cant
actually put the chip in the programmer hehe). Thanks for your help
(everyone).

> {Original Message removed}

2006\09\11@163206 by David VanHorn

picon face
On 9/11/06, Steven Howes <spam_OUTsteveTakeThisOuTspampoundbury.com> wrote:
>
> Thanks I will add the checking loop tomorrow (working from home, cant
> actually put the chip in the programmer hehe). Thanks for your help
> (everyone).


You might have an issue with that simplistic approach, if you have other
tasks running.
Generally I try like hell to avoid "sit and spin" delays.
But, it is the simple way, if it works for you.

2006\09\11@165201 by Steven Howes

picon face
part 1 829 bytes content-type:text/plain; (decoded quoted-printable)

Waits are not much of an issue for this PIC. It links to others that will wait if this one is busy. It could way a few seconds and nothing would notice.

{Original Message removed}

2006\09\11@185837 by Tamas Rudnai

face picon face
I thought the best for time critical app is to have a shadow RAM for the
EEPROM so that when you read data you do not need to access to the EEPROM
and then when you write data you just put the new data to the place and
indicate somewhere (in a bitfield for example) that the place had been
changed. Next time when an interrupt occurs you can check whenever the
shadow had been changed and you can write the changed bytes into the EEPROM
-- when finished a new interrupt will be triggered..and so on. The only
problem is how to start the writing mechanism -- so that if there is no any
data waiting to be written already, you have to start the whole manually
(with an initial write) or do some tricks when timer or other interrupts
occur making sure not interfering with the EEIF.

Tamas


On 11/09/06, Maarten Hofman <.....cashimorKILLspamspam@spam@gmail.com> wrote:
{Quote hidden}

> -

2006\09\11@190254 by Jinx

face picon face
> Is there some delay between consecutive writes ?

Parameter D122, page 235 of  DS41262

http://ww1.microchip.com/downloads/en/DeviceDoc/41262C.pdf

2006\09\11@204829 by Bob Axtell

face picon face
Tamas Rudnai wrote:
> I thought the best for time critical app is to have a shadow RAM for the
> EEPROM so that when you read data you do not need to access to the EEPROM
> and then when you write data you just put the new data to the place and
> indicate somewhere (in a bitfield for example) that the place had been
> changed. Next time when an interrupt occurs you can check whenever the
> shadow had been changed and you can write the changed bytes into the EEPROM
> -- when finished a new interrupt will be triggered..and so on. The only
> problem is how to start the writing mechanism -- so that if there is no any
> data waiting to be written already, you have to start the whole manually
> (with an initial write) or do some tricks when timer or other interrupts
> occur making sure not interfering with the EEIF.
>
> Tamas
>
>  
>  
Just a comment or two. Using a shadow ram is fine, but sometimes, due to
ESD or whatever, the shadow
ram might get corrupted, and could cause a disaster.

What I have found is that if you use a shadow, you need to re-read the
shadow ram whenever a checksum
fails to match, in additione to changes in EPROM that are needed.

But there is a more serious problem, at least with recent PICs (nanowatt
series)- the EEPROM data itself drops
bits at random with usage. Microchip recommends a "refresh cycle", but
their strategy does not include any correction.
I have adopted a "best 2 of 3" or "best 3 of 5" algorithm whenever the
data is critical to make the EEPROM work as
well as it did before (compared to PIC16CExxx EEPROM devices). The way
it works is that all 3 are read, and if all
match, the variable is used; but if even ONE fails to match, then all 3
are rewritten. Unfortunately, the algorithm is lengthy
code-wise.


--Bob

2006\09\11@220540 by Maarten Hofman

face picon face
2006/9/11, Tamas Rudnai <tamas.rudnaispamKILLspamgmail.com>:
>
> I thought the best for time critical app is to have a shadow RAM for the
> EEPROM so that when you read data you do not need to access to the EEPROM
> and then when you write data you just put the new data to the place and
> indicate somewhere (in a bitfield for example) that the place had been
> changed. Next time when an interrupt occurs you can check whenever the
> shadow had been changed and you can write the changed bytes into the
> EEPROM
> -- when finished a new interrupt will be triggered..and so on. The only
> problem is how to start the writing mechanism -- so that if there is no
> any
> data waiting to be written already, you have to start the whole manually
> (with an initial write) or do some tricks when timer or other interrupts
> occur making sure not interfering with the EEIF.
>
> Tamas


All excellent suggestions Tamas, and I agree with you that it could be a
solution in certain cases. It sounds similar to my 44780 routine that just
writes a character to the display every 160us from an area in RAM, thereby
making LCD operations as simple as storing a value, and allowing you to
"read back" and have fast scrolling operations.

Of course, in my application I had no RAM left, and therefore reads and
writes to the EEPROM were needed.

Greetings,
Maarten Hofman.

2006\09\12@040244 by Steven Howes

picon face
>
> Parameter D122, page 235 of  DS41262
>
> ww1.microchip.com/downloads/en/DeviceDoc/41262C.pdf
>


Do excuse me, I appear to have been blind the past few days. I looked
for that and couldn't see it. Thanks.

Steve

2006\09\12@062403 by Vasile Surducan

face picon face
On 9/12/06, Steven Howes <.....steveKILLspamspam.....poundbury.com> wrote:
> >
> > Parameter D122, page 235 of  DS41262
> >
> > ww1.microchip.com/downloads/en/DeviceDoc/41262C.pdf
> >
>
>
> Do excuse me, I appear to have been blind the past few days. I looked
> for that and couldn't see it. Thanks.

  The erase/write cycle time ?

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