A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
|
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. _______________________________ |
|
|
|
--- In , Chad Russel <chadrussel@y...> wrote: > 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 I've been developing sw for 25 years and taught 5 years at the college level. Too often I've seen people fix a symptom and not the underlying problem. Eventually, it comes back to haunt them. Fix it now or fix it later. When I can't fully explain why my fix solves the problem, it keeps gnawing at me. Maybe I'm just picky but I like to know that my code is correct and doesn't have a landmine to step on. |
|
|
|
--- In , "Phil" <phil1960us@y...> wrote: > When I can't fully explain why my fix solves the > problem, it keeps gnawing at me. Maybe I'm just picky but I like to > know that my code is correct and doesn't have a landmine to step on. Did you check the errata for this part? Some revs of the silicon have an issue with writing to EEPROM and there is a work around provided. Might be worth reading... |
|
|
|
> I've been developing sw for 25 years and taught 5 years at the college > level. Too often I've seen people fix a symptom and not the > underlying problem. Eventually, it comes back to haunt them. Fix it > now or fix it later. When I can't fully explain why my fix solves the > problem, it keeps gnawing at me. Maybe I'm just picky but I like to > know that my code is correct and doesn't have a landmine to step on. Post your code here and we will take a look at it... Regards, Igor |
|
uh, dang, that's it. I should have checked the errata (I'll write that 100 times...). Unfortunately, their work around is a mess - sleep while writing. I dont think my app can tolerate the timer being suspended even for a few cycles as it accumulates. I'll just stick with verify/retry. I have yet to see a verify failure with my "wren" fix. Interestingly, they clear WREN in their example code right after the sleep instruction. This also affects 16F627As and 16F628As made before week 20 of 2004. Thanks, Scott! --- In , "Scott Lee" <midl_man@y...> wrote: > > --- In , "Phil" <phil1960us@y...> wrote: > > When I can't fully explain why my fix solves the > > problem, it keeps gnawing at me. Maybe I'm just picky but I like to > > know that my code is correct and doesn't have a landmine to step on. > > Did you check the errata for this part? Some revs of the silicon have > an issue with writing to EEPROM and there is a work around provided. > Might be worth reading... |
|
|
|
Phil, Strange, I never had problems with my '628A's EEPROM-write, altough I they are made before that date. I think it's time you showed us your code, and I'll show you the code that I use (which is very standard I think). BSF STATUS, RP0 ; Bank1 MOVFW CONFIG_ADDR ; MOVWF EEADR ; Address to write MOVFW CONFIG_DATA ; MOVWF EEDATA ; Data to write BSF EECON1, WREN ; Enable Write BCF INTCON, GIE ; Disable Interrupts MOVLW 0x55 ; Write 0x55 MOVWF EECON2 ; MOVLW 0xAA ; Write 0xAA MOVWF EECON2 ; BSF EECON1, WR ; set WR bit BTFSC EECON1, WR ; still set? GOTO $-1 ; wait until cleared BCF EECON1, WREN ; Disable more Writes BSF INTCON, GIE ; Enable Interrupts BCF STATUS, RP0 ; Bank0 Hope we'll tackle this problem soon, Kees Stenekes --- Phil <> wrote: > uh, dang, that's it. I should have checked the > errata (I'll write > that 100 times...). > > Unfortunately, their work around is a mess - sleep > while writing. I > dont think my app can tolerate the timer being > suspended even for a > few cycles as it accumulates. I'll just stick with > verify/retry. I > have yet to see a verify failure with my "wren" fix. > Interestingly, > they clear WREN in their example code right after > the sleep instruction. > > This also affects 16F627As and 16F628As made before > week 20 of 2004. > > Thanks, Scott! > > --- In , "Scott Lee" > <midl_man@y...> wrote: > > > > --- In , "Phil" > <phil1960us@y...> wrote: > > > When I can't fully explain why my fix solves > the > > > problem, it keeps gnawing at me. Maybe I'm just > picky but I like to > > > know that my code is correct and doesn't have a > landmine to step on. > > > > Did you check the errata for this part? Some revs > of the silicon have > > an issue with writing to EEPROM and there is a > work around provided. > > Might be worth reading... _______________________________ |
|
|
|
I am with you, however the underlying problem seems to be with Microchip. We can contact Microchip for input, accept that what they suggest works and leave it at that, or try to read the mind of the silicon. :) Chad --- Phil <> wrote: > --- In , Chad Russel <chadrussel@y...> wrote: > > 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 > > > > I've been developing sw for 25 years and taught 5 years at the > college > level. Too often I've seen people fix a symptom and not the > underlying problem. Eventually, it comes back to haunt them. Fix it > now or fix it later. When I can't fully explain why my fix solves > the > problem, it keeps gnawing at me. Maybe I'm just picky but I like to > know that my code is correct and doesn't have a landmine to step on. ===== My software has no bugs, only undocumented features. _______________________________ |
|
ok, I'll post it. The main difference I see between yours and mine is that I use EEIF to determine completion and you use WR bit. Datasheet implies both should work (yours is a couple bytes shorter and its more portable, I may switch). Are your config and data registers supposed to be in bank 1? I prefer using BANKSEL since I use this code on multiple PICs and Microchip keeps moving the eeprom SFRs around. banksel makes it easy to move around. address is in eeaddress and data is in W. note the verify code at the end. I suppose yahoo will ruin the formatting... BANKSEL vtmp movwf vtmp ; save data for verification, added 10/9/04 BANKSEL EEDATA movwf EEDATA ; value to be written in W BANKSEL eeaddress movfw eeaddress ; get write address BANKSEL EEADR movwf EEADR ; write address bsf EECON1, WREN ; enable write bcf INTCON, GIE ; disable ints movlw 0x55 ; voodoo sequence - see datasheet for details movwf EECON2 movlw 0xAA movwf EECON2 bsf EECON1, WR ; start write sequence bcf EECON1, WREN ; clear enable bit added 10/9/04 BANKSEL PIR1 ; change for 877 eew0 btfss PIR1,EEIF ; is the EE flag set? goto eew0 ; N: try again bcf PIR1,EEIF ; Y: clear it bsf INTCON, GIE ; re-enable ints ; ; verify write, added 10/07/04 ; call eeread ; read the location we just wrote to subwf vtmp,w ; get the original value skpnz ; Is the value written same as read? return ; Y: return movfw vtmp ; N: set up to retry goto eewrite ; retry. --- In , Kees Stenekes <knalkeez@y...> wrote: > Phil, > > Strange, I never had problems with my '628A's > EEPROM-write, altough I they are made before that > date. > I think it's time you showed us your code, and I'll > show you the code that I use (which is very standard I > think). > > BSF STATUS, RP0 ; Bank1 > MOVFW CONFIG_ADDR ; > MOVWF EEADR ; Address to write > MOVFW CONFIG_DATA ; > MOVWF EEDATA ; Data to write > BSF EECON1, WREN ; Enable Write > BCF INTCON, GIE ; Disable Interrupts > MOVLW 0x55 ; Write 0x55 > MOVWF EECON2 ; > MOVLW 0xAA ; Write 0xAA > MOVWF EECON2 ; > BSF EECON1, WR ; set WR bit > BTFSC EECON1, WR ; still set? > GOTO $-1 ; wait until cleared > BCF EECON1, WREN ; Disable more Writes > BSF INTCON, GIE ; Enable Interrupts > BCF STATUS, RP0 ; Bank0 > > Hope we'll tackle this problem soon, > > Kees Stenekes > > --- Phil <phil1960us@y...> wrote: > > > > > uh, dang, that's it. I should have checked the > > errata (I'll write > > that 100 times...). > > > > Unfortunately, their work around is a mess - sleep > > while writing. I > > dont think my app can tolerate the timer being > > suspended even for a > > few cycles as it accumulates. I'll just stick with > > verify/retry. I > > have yet to see a verify failure with my "wren" fix. > > Interestingly, > > they clear WREN in their example code right after > > the sleep instruction. > > > > This also affects 16F627As and 16F628As made before > > week 20 of 2004. > > > > Thanks, Scott! > > > > --- In , "Scott Lee" > > <midl_man@y...> wrote: > > > > > > --- In , "Phil" > > <phil1960us@y...> wrote: > > > > When I can't fully explain why my fix solves > > the > > > > problem, it keeps gnawing at me. Maybe I'm just > > picky but I like to > > > > know that my code is correct and doesn't have a > > landmine to step on. > > > > > > Did you check the errata for this part? Some revs > > of the silicon have > > > an issue with writing to EEPROM and there is a > > work around provided. > > > Might be worth reading... > > > > > > > > > > _______________________________ |
|
|
|
My config- and data registers are located from address 0x0070 (accessible in all banks), typical for a 16f628a. BANKSEL is better for running on different pics indeed. The other difference I see is that you clear the WREN-bit BEFORE you check for the end-of-write. I don't know if that has anything to do with it, but I will try your code tomorrow and see what happens. Kees. --- Phil <> wrote: > ok, I'll post it. The main difference I see between > yours and mine is > that I use EEIF to determine completion and you use > WR bit. Datasheet > implies both should work (yours is a couple bytes > shorter and its more > portable, I may switch). Are your config and data > registers supposed > to be in bank 1? I prefer using BANKSEL since I use > this code on > multiple PICs and Microchip keeps moving the eeprom > SFRs around. > banksel makes it easy to move around. > > address is in eeaddress and data is in W. note the > verify code at the > end. I suppose yahoo will ruin the formatting... > BANKSEL vtmp > movwf vtmp ; save data for verification, added > 10/9/04 > BANKSEL EEDATA > movwf EEDATA ; value to be written in W > BANKSEL eeaddress > movfw eeaddress ; get write address > BANKSEL EEADR > movwf EEADR ; write address > bsf EECON1, WREN ; enable write > bcf INTCON, GIE ; disable ints > movlw 0x55 ; voodoo sequence - see datasheet for > details > movwf EECON2 > movlw 0xAA > movwf EECON2 > bsf EECON1, WR ; start write sequence > bcf EECON1, WREN ; clear enable bit added 10/9/04 > > BANKSEL PIR1 ; change for 877 > eew0 > btfss PIR1,EEIF ; is the EE flag set? > goto eew0 ; N: try again > bcf PIR1,EEIF ; Y: clear it > bsf INTCON, GIE ; re-enable ints > > ; > ; verify write, added 10/07/04 > ; > call eeread ; read the location we just wrote to > subwf vtmp,w ; get the original value > skpnz ; Is the value written same as read? > return ; Y: return > movfw vtmp ; N: set up to retry > goto eewrite ; retry. > --- In , Kees Stenekes > <knalkeez@y...> wrote: > > Phil, > > > > Strange, I never had problems with my '628A's > > EEPROM-write, altough I they are made before that > > date. > > I think it's time you showed us your code, and > I'll > > show you the code that I use (which is very > standard I > > think). > > > > BSF STATUS, RP0 ; Bank1 > > MOVFW CONFIG_ADDR ; > > MOVWF EEADR ; Address to write > > MOVFW CONFIG_DATA ; > > MOVWF EEDATA ; Data to write > > BSF EECON1, WREN ; Enable Write > > BCF INTCON, GIE ; Disable Interrupts > > MOVLW 0x55 ; Write 0x55 > > MOVWF EECON2 ; > > MOVLW 0xAA ; Write 0xAA > > MOVWF EECON2 ; > > BSF EECON1, WR ; set WR bit > > BTFSC EECON1, WR ; still set? > > GOTO $-1 ; wait until cleared > > BCF EECON1, WREN ; Disable more Writes > > BSF INTCON, GIE ; Enable Interrupts > > BCF STATUS, RP0 ; Bank0 > > > > Hope we'll tackle this problem soon, > > > > Kees Stenekes > > > > > > > > --- Phil <phil1960us@y...> wrote: > > > > > > > > uh, dang, that's it. I should have checked the > > > errata (I'll write > > > that 100 times...). > > > > > > Unfortunately, their work around is a mess - > sleep > > > while writing. I > > > dont think my app can tolerate the timer being > > > suspended even for a > > > few cycles as it accumulates. I'll just stick > with > > > verify/retry. I > > > have yet to see a verify failure with my "wren" > fix. > > > Interestingly, > > > they clear WREN in their example code right > after > > > the sleep instruction. > > > > > > This also affects 16F627As and 16F628As made > before > > > week 20 of 2004. > > > > > > Thanks, Scott! > > > > > > --- In , "Scott Lee" > > > <midl_man@y...> wrote: > > > > > > > > --- In , "Phil" > > > <phil1960us@y...> wrote: > > > > > When I can't fully explain why my fix > solves > > > the > > > > > problem, it keeps gnawing at me. Maybe I'm > just > > > picky but I like to > > > > > know that my code is correct and doesn't > have a > > > landmine to step on. > > > > > > > > Did you check the errata for this part? Some > revs > > > of the silicon have > > > > an issue with writing to EEPROM and there is a > > > work around provided. > > > > Might be worth reading... > > > > > > > > > > > > > > > > > > > > > > _______________________________ > _______________________________ |
|
|
|
--- In , Kees Stenekes <knalkeez@y...> wrote: > My config- and data registers are located from address > 0x0070 (accessible in all banks), typical for a > 16f628a. BANKSEL is better for running on different > pics indeed. > The other difference I see is that you clear the > WREN-bit BEFORE you check for the end-of-write. I > don't know if that has anything to do with it, but I > will try your code tomorrow and see what happens. I wasn't clearing the WREN bit at all before, adding that instruction made my eewrite routine work reliably. All the WREN bit is supposed to do, according to the datasheet, is inhibit the setting of WR bit. Clearly, it has more effect than just that. Just to be clear, the code I posted works reliably for me. The WREN and retry code was added during this thread. If you are going to try the code, remove the bcf EECON1, WREN line. With out that line, I was getting about 10% write failures. By the way, the Microchip simulator doesn't update the EEPROM location until my code tests the EEIF bit. I dont know if that has any bearing on how the chip actually works, though. |
|
Hello Phil, *DO NOT* use "bcf INTCON, GIE" do disable interrupts! This is how you disable interrupts on PIC MCUs: loop bcf INTCON, GIE btfsc INTCON, GIE goto loop For details, download and read AN576 "Techniques to Disable Global Interrupts". You should clear WR bit *AFTER* writing to eeprom is completed (after checking PIR1,EEIF), not before! Everything else is OK although I like placing few NOPs after "bsf EECON1, WR" :) Regards, Igor |
|
|