eeprom write errors?

Started by Phil October 11, 2004

I'm using a 16F648A and am seeing some errors when writing data to
eeprom. I put some verification code in my eewrite routine and am
frequently getting back something different from what I wrote.
Usually, this happens once every 4-10 writes and appears to be
somewhat random. I disable interrupts in my eewrite code so the
sequence should be execute undisturbed. The errors are for real, by
the way, I read back the eeprom my programmer and the data is, indeed,
written incorrectly.

some environment info: 20 mhz, same problem with 2 different power
sources - one at 4.5V, one at 5V. Bypass caps in place. Current draw
and heat look ok. watchdog, bod, lvprogramming off

I've fixed the problem by simply retrying the write. However, I
didn't see anything obvious on microchip's site about eeprom errors
and I'm concerned that something worse is going on. Is the eeprom
generally unreliable (dont think that would be case, though). I'm
going to try a 16F628A I have here but I'll need to trim my code down.
sigh.

any ideas?




> any ideas?

Most common problems: ISR not disabled, page selection, bank selection.

Regards,
Igor



hmmm, it takes some time to do a eeprom-write. There
is a status-bit that indicates the end-of-a-write.
Maybe there lies your problem.

Kees
--- Phil <> wrote:

>
> I'm using a 16F648A and am seeing some errors when
> writing data to
> eeprom. I put some verification code in my eewrite
> routine and am
> frequently getting back something different from
> what I wrote.
> Usually, this happens once every 4-10 writes and
> appears to be
> somewhat random. I disable interrupts in my eewrite
> code so the
> sequence should be execute undisturbed. The errors
> are for real, by
> the way, I read back the eeprom my programmer and
> the data is, indeed,
> written incorrectly.
>
> some environment info: 20 mhz, same problem with 2
> different power
> sources - one at 4.5V, one at 5V. Bypass caps in
> place. Current draw
> and heat look ok. watchdog, bod, lvprogramming off
>
> I've fixed the problem by simply retrying the write.
> However, I
> didn't see anything obvious on microchip's site
> about eeprom errors
> and I'm concerned that something worse is going on.
> Is the eeprom
> generally unreliable (dont think that would be case,
> though). I'm
> going to try a 16F628A I have here but I'll need to
> trim my code down.
> sigh.
>
> any ideas? >
>

__________________________________




thanks. The fact that its random implies interrupts of some sort but
interrupts are definitely disabled. Using unused port pins and a
scope, I was able to see that no ints were getting in. I've been over
the bank/page stuff until I can't see straight - given the apparent
random nature, I think its not that.

--- In , "Igor Janjatovic" <kodrat@p...> wrote:
> > any ideas?
>
> Most common problems: ISR not disabled, page selection, bank selection.
>
> Regards,
> Igor





--- In , "Phil" <phil1960us@y...> wrote:
>
> thanks. The fact that its random implies interrupts of some sort
but
> interrupts are definitely disabled. Using unused port pins and a
> scope, I was able to see that no ints were getting in. I've been
over
> the bank/page stuff until I can't see straight - given the apparent
> random nature, I think its not that.

Is the chip doing anything else at the time? For example is the
USART in use?

How about posting your write code?




Thanks to those who made suggestions. I found something that makes
the symptom go away - I wasn't actually clearing the WREN bit, ever.
Clearing it after initiating a write seems to solve the problem. The
docs are pretty clear about keeping it low for protection from errant
writes but nothing else. I'll have to keep looking for the real
problem but at least I can debug my application now.





--- In , "Scott Lee" <midl_man@y...> wrote:
...
>
> Is the chip doing anything else at the time? For example is the
> USART in use?
>

I disable all interrupts during the write sequence and watchdog & BOD
are disabled. So, no, there shouldn't be anything else going on. As
I said a second ago, WREN has some impact on this though I can't
believe that's the root cause. thanks for the thought.



I think you have found the problem. My instructions say after setting
WR bit, enable interrupts is used, and clear the WREN bit. It must do
something else we are not privy to.

Chad

--- Phil <> wrote:

>
> Thanks to those who made suggestions. I found something that makes
> the symptom go away - I wasn't actually clearing the WREN bit, ever.
> Clearing it after initiating a write seems to solve the problem. The
> docs are pretty clear about keeping it low for protection from errant
> writes but nothing else. I'll have to keep looking for the real
> problem but at least I can debug my application now. >
>


=====
My software has no bugs, only undocumented features.
__________________________________





--- In , Chad Russel <chadrussel@y...> wrote:
> I think you have found the problem. My instructions say after setting
> WR bit, enable interrupts is used, and clear the WREN bit. It must do
> something else we are not privy to.
>

I guess I'm not ready to declare victory - still think its something
else I'm doing wrong. Though, it wouldn't be the first time some
undocumented side effect was necessary for proper operation of a
peripheral...

Phil




Sorry, that was a bad typo:

After setting WR bit, enable interrupts (if used), then clear the WREN
bit. If it works, then just do it. :-p It is a PhD's job to analyze
everything to death.

Chad

--- Phil <> wrote:

>
> --- In , Chad Russel <chadrussel@y...> wrote:
> > I think you have found the problem. My instructions say after
> setting
> > WR bit, enable interrupts is used, and clear the WREN bit. It must
> do
> > something else we are not privy to.
> >
>
> I guess I'm not ready to declare victory - still think its something
> else I'm doing wrong. Though, it wouldn't be the first time some
> undocumented side effect was necessary for proper operation of a
> peripheral...
>
> Phil >
>


=====
My software has no bugs, only undocumented features.
_______________________________