|
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? |
|
|
eeprom write errors?
Started by ●October 11, 2004
Reply by ●October 11, 20042004-10-11
Reply by ●October 11, 20042004-10-11
|
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? > > __________________________________ |
Reply by ●October 11, 20042004-10-11
|
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 |
|
|
Reply by ●October 11, 20042004-10-11
|
--- 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? |
|
|
Reply by ●October 11, 20042004-10-11
|
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. |
|
|
Reply by ●October 11, 20042004-10-11
|
--- 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. |
Reply by ●October 11, 20042004-10-11
|
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. __________________________________ |
|
|
Reply by ●October 11, 20042004-10-11
|
--- 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 |
|
|
Reply by ●October 11, 20042004-10-11
|
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. _______________________________ |
|
|
