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

Exact match. Not showing close matches.
PICList Thread
'[PIC:] EEPROM write reliability'
2004\02\24@010831 by Picdude

flavicon
face
Hi all,

In a PIC16F627 application I recently developed, I am having a code-hang problem.  My best diagnosis so far, is that the code is getting stuck in the EEPROM write routine [code posted at the end of this email] which is called from a main code loop.  Interrupt processing seems to be working fine still, even though this main loop is locked up.

In the write routine, I'm waiting on the EEIF flag to be set, indicating that the write operation is complete, but I'm guessing that this is where it's getting stuck.

The EEPROM writes happen in groups of 5 (all calling this routine), and I'm not verifying that the write operation was successful by checking the actual value saved (at least, not yet).  I'm also not using a watchdog timer yet.  The 2 other interrupts are TMR0 which updates the multiplexed display, and TMR2 which checks for and processes an external signal.

Any idea what could be going wrong here?
Cheers,
-Neil.



;-----------------------------------------------------------------
; Write data to EEPROM (location supplied in W, data in E_DATA)
;-----------------------------------------------------------------

WriteEEData:
       bcf        PIR1,EEIF        ; Reset write-complete flag

       bsf        STATUS,RP0        ; Bank 1
       movwf        EEADR
       bcf        STATUS,RP0        ; Bank 0
       movf        E_DATA,W        ; Get data to be stored
       bcf        PIR1,EEIF        ; Ensure interrupt flag off while in bank 0
       bsf        STATUS,RP0        ; Bank 1
       movwf        EEDATA

       bsf        EECON1,WREN        ; Enable writes
       bcf        INTCON,GIE        ; Disable interrupts
       movlw        H'55'                ; Special seq
       movwf        EECON2                ; ...
       movlw        H'AA'                ; ...
       movwf        EECON2                ; ...
       bsf        EECON1,WR        ; Start write operation
       bcf        EECON1,WREN        ; Disable writes
       bcf        STATUS,RP0        ; Bank to bank 0

       bsf        INTCON,GIE        ; Re-enable interrupts

WriteEEWait:
       btfss        PIR1,EEIF        ; Check EEIF flag for write completion
       goto        WriteEEWait

WriteEEDataDone:
       return

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\24@012815 by Ken Pergola

flavicon
face
Neil wrote:

> Any idea what could be going wrong here?

Hi Neil,

Still looking over your code, but just a few comments right now:

I don't see anywhere in your code where you are clearing bit 7 of EEADR --
it should be set to zero for the device you are using.
Are you ANDing the W register (EEPROM address) with 0x7F before calling your
write routine?

Also, it might be better to re-enable interrupts only if they were
previously enabled when you entered the EEPROM write routine instead of
unconditionally enabling them. It might not matter in this specific
application of yours, but this might be something that will bite you in the
future.

Perhaps you could toggle an I/O pin in your write routine and 'scope to see
if you are actually getting stuck there.

Keep us posted...let me go back to your code...

Best regards,

Ken Pergola

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\02\24@014306 by Ken Pergola

flavicon
face
Hi Neil,

Also, for safety, I feel it would be best to explicitly clear STATUS, RP1 in
your EEPROM WRITE routine.
Your routine makes the assumption that the RP1 bit is already cleared.
But we are not seeing the entire code so maybe this is one of your function
preconditions?

For now, you might just want to use BANKSEL even though it will be somewhat
wasteful in terms of redundancy in certain cases.

Best regards,

Ken Pergola

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2004\02\24@020625 by Ken Pergola

flavicon
face
Hi Neil,

Note that I added BANKSEL directives to your code.
I'll leave it up to you to see which ones could be removed because of
redundancy.
I may have made some boo-boos, so double-check things carefully.
Like I said before, you can add code to this routine to see if interrupts
were enabled or not.
Then based on this boolean condition, you can conditional enable or leave
interrupts disabled upon exit.

You might also want to investigate the state of WRERR upon power-up.
Have you checked all errata notes on the PIC16F627?
Just for kicks, you also might want to check the WR bit to ensure it is
getting cleared after a write completes.

Also (depending upon the situation) it is good practice to point the EEPROM
address register to another unused location upon exit as one of several
measures to help prevent corruption of the EEPROM location you just wrote.






;-----------------------------------------------------------------
; Write data to EEPROM (location supplied in W, data in E_DATA)
;-----------------------------------------------------------------

WriteEEData:
       BANKSEL PIR1
       bcf     PIR1,EEIF       ; Reset write-complete flag

       BANKSEL EEADR
       movwf   EEADR

       BANKSEL E_DATA
       movf    E_DATA,W        ; Get data to be stored

       BANKSEL PIR1
       bcf     PIR1,EEIF       ; Ensure interrupt flag off while in bank 0

       BANKSEL EEDATA
       movwf   EEDATA

     ; Previous BANKSEL also takes care of the following registers

       bsf     EECON1,WREN     ; Enable writes
       bcf     INTCON,GIE      ; Disable interrupts
       movlw   H'55'           ; Special seq
       movwf   EECON2          ; ...
       movlw   H'AA'           ; ...
       movwf   EECON2          ; ...
       bsf     EECON1,WR       ; Start write operation
       bcf     EECON1,WREN     ; Disable writes

       bsf     INTCON,GIE      ; Re-enable interrupts

       BANKSEL PIR1

WriteEEWait:
       btfss   PIR1,EEIF       ; Check EEIF flag for write completion
       goto    WriteEEWait

WriteEEDataDone:
       return



Hope this helps more than it hurts. :)


Best regards,

Ken Pergola

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\02\24@022942 by Jinx

face picon face
> Any idea what could be going wrong here?

Neildude, I use this 628 routine, a little different to yours but it
works OK. Note that bank0 and bank1 macros or BANKSEL
address both RP bits

        bank1
        movwf   eedata   ;data already in W
        bank0
        movf    eea,w    ;eea is a Bank0 variable
        bank1
        movwf   eeadr

        bcf     intcon,gie
        bsf     eecon1,wren
        movlw   0x55
        movwf   eecon2
        movlw   0xaa
        movwf   eecon2
        bsf     eecon1,wr     ;initiate write

        bank0
        btfss   pir1,eeif     ;wait for write complete
        goto    $-1
        bcf     pir1,eeif
        return

I wonder if there's a complication with the timers in your app ?
Maybe when you re-enable the interupts there's a flag set that
causes an ISR to be executed. Perhaps test the flags before
you re-enable GIE

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\24@065814 by David Duffy

flavicon
face
Picdude wrote:

{Quote hidden}

Here's some working EE code on a '628.

;********************************************************************
;*      eeprom interrupt handler                                    *
;********************************************************************
int_ee:                         ;
       bcf     eeif            ;clear the interrupt that called us
       bcf     ee_busy         ;clear our eeprom busy flag
       bank1                   ;bank 1
       bcf     wren            ;disable eeprom writes
       bank0                   ;bank 0
       goto    exit_int        ;

;********************************************************************
;* 'ee_write' writes one byte.                                      *
;* enter with eeprom address in w and eeprom data in ee_temp.       *
;********************************************************************
ee_write:                       ;
       btfsc   ee_busy         ;is the eeprom busy from a previous write?
       goto    ee_write        ;yes, loop & wait
       bcf     gie             ;no, disable the global interupt
       bank1                   ;bank 1
       movwf   eeadr           ;set up eeprom address
       movf    ee_temp,w       ;get data for eeprom saved in calling
routine
       movwf   eedata          ;set eeprom data
       bsf     wren            ;enable eeprom writing
       movlw   h'55'           ;
       movwf   eecon2          ;eeprom write unlock sequence
       movlw   h'aa'           ;
       movwf   eecon2          ;eeprom write unlock sequence
       bsf     wr              ;initiate data eeprom write
       bank0                   ;bank 0
       bsf     ee_busy         ;set flag to say eeprom is busy
       bsf     gie             ;re-enable the global interupt
       return                  ;exit

;********************************************************************

I do the first write, then exit back to the main loop right away
to deal with other tasks. Checking the eeprom busy state at
the start of the eeprom write is a more efficient way to do it.
Clearing the write enable during writing *may* be causing
your problem. I wait until the write is finished and that works.
David...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\02\25@192022 by Picdude

flavicon
face
On Tuesday 24 February 2004 12:24 am, Ken Pergola scribbled:
> I don't see anywhere in your code where you are clearing bit 7 of EEADR --
> it should be set to zero for the device you are using.

It defaults to this when I set the address into the W before calling the EEPROM-write routine.

> Are you ANDing the W register (EEPROM address) with 0x7F before calling
> your write routine?

Not specifically, but I just tried that, and no change.


> Also, it might be better to re-enable interrupts only if they were
> previously enabled when you entered the EEPROM write routine instead of
> unconditionally enabling them. It might not matter in this specific
> application of yours, but this might be something that will bite you in the
> future.

Good idea.  Unfortunately for this app, they must always be enabled,


> Perhaps you could toggle an I/O pin in your write routine and 'scope to see
> if you are actually getting stuck there.

Holding off on this for now, since all pins are in use, and the circuit is on a PCB already.  Luckily I socketed the chip.


Much thanks,
-Neil.

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2004\02\25@192403 by Picdude

flavicon
face
On Tuesday 24 February 2004 12:40 am, Ken Pergola scribbled:
> Hi Neil,
>
> Also, for safety, I feel it would be best to explicitly clear STATUS, RP1
> in your EEPROM WRITE routine.
> Your routine makes the assumption that the RP1 bit is already cleared.
> But we are not seeing the entire code so maybe this is one of your function
> preconditions?

I'm sure that RP1 does not change, but I added explicit code to do this in the write routine just now, and no change to the problem still.

>
> For now, you might just want to use BANKSEL even though it will be somewhat
> wasteful in terms of redundancy in certain cases.

I still prefer explicit instructions to set/clear the appropriate bits, since I feel it's a bit more readable/familiar to me.

>
> Best regards,
>
> Ken Pergola

Cheers,
-Neil.

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2004\02\25@194305 by Picdude

flavicon
face
On Tuesday 24 February 2004 01:04 am, Ken Pergola scribbled:
> Hi Neil,
>
> Note that I added BANKSEL directives to your code.
> I'll leave it up to you to see which ones could be removed because of
> redundancy.
> I may have made some boo-boos, so double-check things carefully.
> Like I said before, you can add code to this routine to see if interrupts
> were enabled or not.
> Then based on this boolean condition, you can conditional enable or leave
> interrupts disabled upon exit.
>
> You might also want to investigate the state of WRERR upon power-up.

This actually won't tell me much for this problem, since the chip does not reset ... the main loop just locks up (my guess is that something causes the wait-for-write complete loop not to exit), but the timer interrupts still get called properly.  It feels like I have a stack problem or other timing issue.

> Have you checked all errata notes on the PIC16F627?

Not recently, but a couple months ago I did, and don't remember anything major issues around this that could cause this problem.  Perhaps I should re-read them.

I did try a brand new chip, but no change still.


> Just for kicks, you also might want to check the WR bit to ensure it is
> getting cleared after a write completes.

Hmmm.... I'll go experiment.


> Also (depending upon the situation) it is good practice to point the EEPROM
> address register to another unused location upon exit as one of several
> measures to help prevent corruption of the EEPROM location you just wrote.

I always thought that the write sequence would prevent that, but it sounds fine to me if this has ever been a problem still.


{Quote hidden}

I'll try this out shortly, and get back to you.

Thanks,
-Neil.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

2004\02\25@200238 by Jinx

face picon face
> > Also, it might be better to re-enable interrupts only if they were

> Unfortunately for this app, they must always be enabled

Can you arrange for the code to be executed in between timer
interrupts ? ie wait until both TMR0 and TMR2 IRQs have just
occured before entering the EE routine

In your original code you clear WREN after setting WR. All examples
I've seen (eg 13.2 in the 16F628 manual amongst others) simply set
WREN. Have you tried it with that taken out or putting it somewhere
else? However, once WR is set, anything short of a reset won't stop
the write so that could be chasing rainbows

IMHO I think you should verfiy that program flow really is getting
stuck in this routine

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu

2004\02\25@200440 by piclist

flavicon
face
On Wed, 25 Feb 2004, Picdude wrote:

> >         bsf     EECON1,WR       ; Start write operation
> >         bcf     EECON1,WREN     ; Disable writes
> >
> >         bsf     INTCON,GIE      ; Re-enable interrupts
> >
> >         BANKSEL PIR1
> >
> > WriteEEWait:
> >         btfss   PIR1,EEIF       ; Check EEIF flag for write completion
> >         goto    WriteEEWait

Can an interrupt that occurs while waiting for write completion
attempt to read from EEPROM or read/write program memory?

--
John W. Temples, III

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu

2004\02\25@201932 by Jinx

face picon face
> Can an interrupt that occurs while waiting for write completion
> attempt to read from EEPROM or read/write program memory?

AFAIK no manual or EEPROM d/s specifically says you can't
read EE whilst a write is occuring. As the actual write on a micro
is done in h/w on a single byte by a timer/charge pump and doesn't
rely on or affect s/w, maybe you can read other locations during the
~4ms that the write takes. I've never tried that and unfortunately not
able to at the moment

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu

2004\02\25@203012 by piclist

flavicon
face
On Thu, 26 Feb 2004, Jinx wrote:

> > Can an interrupt that occurs while waiting for write completion
> > attempt to read from EEPROM or read/write program memory?
>
> AFAIK no manual or EEPROM d/s specifically says you can't
> read EE whilst a write is occuring.

The datasheets say, "After a write sequence has been initiated,
EECON1, EEADR and EEDATA cannot be modified."

As the actual write on a micro
> is done in h/w on a single byte by a timer/charge pump and doesn't
> rely on or affect s/w, maybe you can read other locations during the
> ~4ms that the write takes. I've never tried that and unfortunately not
> able to at the moment

My question could have been worded better; I was asking whether the OP
was actually trying to do that, since it would be a problem.  You
can't read EEPROM or program memory while an EEPROM write is in
progress.

--
John W. Temples, III

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

2004\02\25@204255 by Ken Pergola

flavicon
face
Hi Neil,

The part you are having trouble with is a PIC16F627 not a PIC16F627A
correct?

The reason I'm asking is because the PIC16F62XA has an errata problem with
EEPROM writes.

Just checking with you.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu

2004\02\25@205539 by Jinx

face picon face
> > AFAIK no manual or EEPROM d/s specifically says you can't
> > read EE whilst a write is occuring.
>
> The datasheets say, "After a write sequence has been initiated,
> EECON1, EEADR and EEDATA cannot be modified."

Where does it say that ? I've looked in the EE sections of the
628 and Mid-range manuals and don't see it

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu

2004\02\25@210823 by piclist

flavicon
face
On Thu, 26 Feb 2004, Jinx wrote:

> > The datasheets say, "After a write sequence has been initiated,
> > EECON1, EEADR and EEDATA cannot be modified."
>
> Where does it say that ? I've looked in the EE sections of the
> 628 and Mid-range manuals and don't see it

That's actually from an 18F datasheet, but I would expect the same
behavior in a 16F.  I've observed program memory reads failing on a
16F during an EEPROM write; I'm assuming that this is because the
EEDATA/EEADR registers are simply non-functional, as noted in the 18F
datasheet, while an EEPROM write is in progress.

--
John W. Temples, III

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu

2004\02\25@212729 by Jinx

face picon face
> That's actually from an 18F datasheet

Ah, I see it, section 6.4. Seems a little late in the piece for
MC to be saying that. I've checked in the 877 manual in case
it was something to do with being able to R/W Flash as well
but no

> I'm assuming that this is because the EEDATA/EEADR
>registers are simply non-functional

There might be an alternative interpretation of

"After a write sequence has been initiated, EECON1, EEADR
and EEDATA cannot be modified."

_could_ mean that once the write has been initiated, the contents
of the registers have been passed on to the h/w for writing and so
that's what will be written. IOW, too late to change them. Perhaps
it's just sloppy writing, notwithstanding your observations

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu

2004\02\25@214015 by Picdude

flavicon
face
On Tuesday 24 February 2004 01:29 am, Jinx scribbled:
> Neildude, I use this 628 routine, a little different to yours but it
> works OK. Note that bank0 and bank1 macros or BANKSEL
> address both RP bits
>
>          ...
>
> I wonder if there's a complication with the timers in your app ?

This is the biggest thing I suspect now.  I just tried your routine above, and it totally froze now.... no display updates, etc.  Odd!?  However, I moved the line that re-enables INTCON (after the EEPROM) write in my routine to now be outside/after the wait-for-EEIF loop, and the whole app works properly.  But interrupts are disabled for so long that there are no display updates during this time, leading to a nasty display flicker ... actually display "blinking". :-(

> Maybe when you re-enable the interupts there's a flag set that
> causes an ISR to be executed. Perhaps test the flags before
> you re-enable GIE

I need to check for this carefully.  Let me go bash my head against the wall a bit more.

Thanks,
-Neil.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu

2004\02\25@214843 by Jinx

face picon face
> Let me go bash my head against the wall a bit more

Hey, at least you know which wall it is now ;-)

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2004\02\25@215050 by Jinx

face picon face
> > I wonder if there's a complication with the timers in your app ?

> This is the biggest thing I suspect now.  I just tried your routine
> above, and it totally froze now.... no display updates, etc.  Odd!?

Note that the particular program it came from didn't use IRQs and
so never re-enable them

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu

2004\02\26@000629 by Picdude

flavicon
face
David's reply/code brought me to thinking about the architecture of my app, so here's some more detail on what I'm doing...

The application is an odometer.  It shows the current mileage (to the nearest mile), but every 1/10th mile (which it gets as a pulse from an external source) it saves the new data to EEPROM.  It takes 4 EEPROM locations to save a new distance value (0-999,999.9 miles).  On startup it reads the EEPROM to know where it left off.  Display intensity changes are also stored in EEPROM, but that happens very rarely.

To address the concern of EEPROM write endurance, I have setup the EEPROM as a 30-unit circular buffer, of 4 bytes each.  It just moves to the next index/location of the circular buffer and writes to that (set of 4 bytes) location.  Each distance value uses 4 bytes, but 5 EEPROM writes -- The first byte is marked as dirty, the distance is then written to the other 3 and the first is then marked as valid.  On startup, all 30 locations are read, and the highest *valid* value is taken as the distance it left off with.

For a 1-million mile odometer, that means 10-million distances written.  Byte 1 of each 4-byte set would get the most abuse at 20 million writes.  But splitting it up across 30 sets means 666,667 max writes for any single EEPROM location.  This is well within the datasheet's EEPROM read/write endurance limits (10mil cycles typical, and 1mil minimum).  For greater comfort level, I'm thought of moving this to an 'F648 (256 bytes of EEPROM), so I can drop the EEPROM abuse to half of this by spreading it over 60 sets of 4 bytes, but another idea I had was that above a certain speed, I could set it to write every mile or so, since the vehicle has to come back to a lower speed before stopping, and that would let it catch back up to the nearest 1/10-mile.  TBD later.
The main code does its initialization stuff, scans for highest saved distance-set, enables 2 timer interrupts, then goes into a loop that updates the display if necessary, and writes a distance-set to EEPROM if necessary.  One of the timer interrupts just updates the multiplexed display periodically, and another polls for pulses at the ports and updates the distance variables if necessary.  If so, it sets a flag to trigger the main loop to write that to EEPROM.

It all works except for the EEPROM write issue, which was also working some time ago during development, but not sure what's causing this problem now.

... just in case you were wondering.

Cheers,
-Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@000633 by Picdude

flavicon
face
On Tuesday 24 February 2004 05:57 am, David Duffy scribbled:
> Here's some working EE code on a '628.
>
>       ...
>
>
> I do the first write, then exit back to the main loop right away
> to deal with other tasks. Checking the eeprom busy state at
> the start of the eeprom write is a more efficient way to do it.
> Clearing the write enable during writing *may* be causing
> your problem. I wait until the write is finished and that works.
> David...

Interesting way to do it.  In my case, I would just wait in a busy-loop until that flag is set, and then continue with the rest of the code.  This is cause the main routine really does not *need* to do anything else during this time.

I can see an easy way to set a timeout with this ... ie: while waiting until the flag is set, I could/should add a "timeout" counter which would assume that something went wrong if the flag was not set in a certain amount of time.  What's a reasonable amount of time for this?  Hopefully it's less than the time between EEPROM writes in my app.  I've calculated that my app can write a new value to EEPROM as fast as every 0.29 secs.  [ Hmmm ... that seems pretty short now that I think about it, but it's the very *worst* case. ]

Cheers,
-Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@001252 by Picdude

flavicon
face
On Wednesday 25 February 2004 07:03 pm, Jinx scribbled:
> > > Also, it might be better to re-enable interrupts only if they were
> >
> > Unfortunately for this app, they must always be enabled
>
> Can you arrange for the code to be executed in between timer
> interrupts ? ie wait until both TMR0 and TMR2 IRQs have just
> occured before entering the EE routine

That will take a bit of thought.  See my other post from a minute ago, where I explain how my code is architected.


> In your original code you clear WREN after setting WR. All examples
> I've seen (eg 13.2 in the 16F628 manual amongst others) simply set
> WREN.

My impression is that disabling it helps prevent spurious writes.  I think I just put it there so that the code can get some work done and out of the way while the EEPROM was off doing its thing.


> Have you tried it with that taken out or putting it somewhere
> else? However, once WR is set, anything short of a reset won't stop
> the write so that could be chasing rainbows

I remember something (from the datasheet or an app note) that said that clearing WREN will not stop a write operation once it has been initiated.  Of course that's the perfect scenario, if the chips operated exactly as intended.


> IMHO I think you should verfiy that program flow really is getting
> stuck in this routine

I really should re-breadboard it, but so far my test of re-enabling interrupts after waiting for the write operation to be completed seems to re-affirm that this is the problem area.  Let me run off and think of an easy way to do this in the existing environment.

Cheers,
-Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@001547 by Picdude

flavicon
face
On Wednesday 25 February 2004 07:02 pm, spamBeGonepiclistSTOPspamspamEraseMEXARGS.COM scribbled:
> Can an interrupt that occurs while waiting for write completion
> attempt to read from EEPROM or read/write program memory?

Nope.  The EEPROM location is only written to during continuous operation.  Reading is done only at the beginning during initialization when the circuit is first powered up.

Cheers,
-Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@001804 by Picdude

flavicon
face
On Wednesday 25 February 2004 07:41 pm, Ken Pergola scribbled:
> Hi Neil,
>
> The part you are having trouble with is a PIC16F627 not a PIC16F627A
> correct?
>
> The reason I'm asking is because the PIC16F62XA has an errata problem with
> EEPROM writes.
>
> Just checking with you.
>
> Best regards,
>
> Ken Pergola

Hmmm.... I've been interchanging these chips as available.  Currently it is a PIC16F627A.  The latest errata sheet I had previously read for these devices was 80073f, but I just got a new one (80151g) that shows what you're talking about.  Let me swap chips and see if it has any effect.  I'll be back.

Thanks,
-Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@010257 by Picdude
flavicon
face
Bingo!  Changed the 16F627A to a 16F628 (using the same code that exhibited the hanging problem), and the odometer works properly again!  I'm going to run an extended overnight test and will post the results tomorrow.

Thanks for all the help.

Cheers,
-Neil.




On Wednesday 25 February 2004 11:28 pm, Picdude scribbled:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@010300 by Jinx

face picon face
> TMR0 which updates the multiplexed display

Do you need to be updating that often ? Presumably using
TMR0 means a fairly short IRQ period, when a refresh rate
as slow as 100Hz would probably be fine. That would put
the update period outside of the 8ms max spec for an EE
write

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@013921 by David Duffy

flavicon
face
Jinx wrote:

>>Can an interrupt that occurs while waiting for write completion
>>attempt to read from EEPROM or read/write program memory?
>>
>>
>
>AFAIK no manual or EEPROM d/s specifically says you can't
>read EE whilst a write is occuring. As the actual write on a micro
>is done in h/w on a single byte by a timer/charge pump and doesn't
>rely on or affect s/w, maybe you can read other locations during the
>~4ms that the write takes. I've never tried that and unfortunately not
>able to at the moment
>

AFAIK, changing EEADR during a write is not good!
IIRC, this one caught me last year. The code I posted
yesterday definately does work correctly and we have
hundreds of units out there working hard all the time.
David...

--
___________________________________________
David Duffy        Audio Visual Devices P/L
U8, 9-11 Trade St, Cleveland 4163 Australia
Ph: +61 7 38210362   Fax: +61 7 38210281
New Web: http://www.audiovisualdevices.com.au
___________________________________________

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@014131 by Jinx

face picon face
> the PIC16F62XA has an errata problem with EEPROM writes.

> Ken Pergola

Thanks for pointing that out. I've just moved from 628 to 628A.
Nothing using EEPROM yet but that's a useful heads-up

http://www.microchip.com/download/lit/suppdoc/errata/80151g.pdf

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\26@014336 by David Duffy

flavicon
face
Picdude wrote:

{Quote hidden}

My application has to monitor a RF remote receiver, a push button, flash
an led and do serial comms in between the eeprom writing and reading
so the wait-while-previous-byte-writing was the best way to go for me.
I think the eeprom byte write time on a 'F628 is in the order of 8-10ms.
David...

--
___________________________________________
David Duffy        Audio Visual Devices P/L
U8, 9-11 Trade St, Cleveland 4163 Australia
Ph: +61 7 38210362   Fax: +61 7 38210281
New Web: http://www.audiovisualdevices.com.au
___________________________________________

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\02\28@133509 by Picdude

flavicon
face
On Thursday 26 February 2004 12:40 am, David Duffy scribbled:
> I think the eeprom byte write time on a 'F628 is in the order of 8-10ms.
> David...


Using the 16F628 instead now, I had tested for a day at a simulated ~1000 MPH, and it worked well, and I've also run it for a day at ~1600MPH !  In both cases, it works well, with the EEPROM saving the 0.1-mile distances reliably.  I've logged 60,000+ simulated miles already.  So the write time is more than fast enough for my original intention of supporting speeds up to 250mph. :-)

Thanks,
-Neil.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

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