Post by thread:Help With 16C84 EEPROM

Hi Folks, I'm trying to write a 16C84 EEPROM and when I do, the PIC Locks up (doesn't return from the Loop polling "WR" in "EECON1"). The Code is: movlw 0 ; Put the Data in EEPROM Address 0 movwf EEADR movlw 0x055 ; Simple Check Pattern movwf EEDATA call EEWRITE . : EEWRITE ; Put the Contents of EEDATA into EEPROM at bsf STATUS, RP0 ; EEADR bsf EECON1 & 0x07F, WREN bcf INTCON, GIE ; Turn Off Interrupts During Write movlw 0x055 movwf EECON2 & 0x07F movlw 0x0AA movwf EECON2 & 0x07F bsf EECON1 & 0x07F, WR bsf INTCON, GIE btfsc EECON1 & 0x07F, WR ; Wait for the EEPROM Write to Complete goto $ - 1 bcf EECON1 & 0x077F, WREN ; Disable the EEPROM From Writing bcf STATUS, RP0 return Data is displayed on three seven-segment LED displays. Only the Timer is used for Interrupts (to switch between the LED displays). When I run this on the MPLAB Simulator, it runs fine (although executes in one cycle, which I find surprising). The code above is identical to what's shown in the Datasheets, except for the "bsf EECON1 & 0x07F, WREN" after the switch to Register Page 1. Does anybody know what I'm doing wrong? Thanx, Myke Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

> From: myke predko <spam_OUTmykeTakeThisOuTPASSPORT.CA> > > Hi Folks, > > I'm trying to write a 16C84 EEPROM and when I do, the PIC Locks up (doesn't > return from the Loop polling "WR" in "EECON1"). Are you sure this is where it's locked up? How do you know if running on a real device? {Quote hidden}> > The Code is: > > movlw 0 ; Put the Data in EEPROM Address 0 > movwf EEADR > movlw 0x055 ; Simple Check Pattern > movwf EEDATA > call EEWRITE > > . > : > > EEWRITE ; Put the Contents of EEDATA into EEPROM at > bsf STATUS, RP0 ; EEADR > bsf EECON1 & 0x07F, WREN > bcf INTCON, GIE ; Turn Off Interrupts During Write > movlw 0x055 > movwf EECON2 & 0x07F > movlw 0x0AA > movwf EECON2 & 0x07F > bsf EECON1 & 0x07F, WR > bsf INTCON, GIE > btfsc EECON1 & 0x07F, WR ; Wait for the EEPROM Write to Complete > goto $ - 1 > bcf EECON1 & 0x077F, WREN ; Disable the EEPROM From Writing > bcf STATUS, RP0 > return > Assuming that your equates are all OK... I can't see anything wrong with this code fragment except perhaps a (harmless) typo on the third last line. It could be an interrupt routine going haywire. You enable interrupts prior to testing WR going low. If the interrupt routine accidentally clears RP0, or assumes that RP0 is cleared and thus messes with the wrong registers, then you'll be in strife. It's a matter of taste, but I prefer to turn off WREN immediately after setting WR, especially if interrupts are enabled while waiting for write completion. This will prevent accidental re-setting of WR which, although the manual doesn't say much about it, could extend the write cycle indefinitely. > Data is displayed on three seven-segment LED displays. Only the Timer is > used for Interrupts (to switch between the LED displays). When I run this > on the MPLAB Simulator, it runs fine (although executes in one cycle, which > I find surprising). Trace it through to see why it is executing so quickly. What precisely is it that is taking only one cycle: is the tight loop bailing out immediately? After resetting the device, does the EEPROM location read 0x55 or is it junk? {Quote hidden}> > The code above is identical to what's shown in the Datasheets, except for > the "bsf EECON1 & 0x07F, WREN" after the switch to Register Page 1. > > Does anybody know what I'm doing wrong? > > Thanx, > > Myke > > Do you ever feel like an XT Clone caught in the Pentium Pro Zone? Yes, but at least I can do floating point division... Regards, SJH Canberra, Australia

Hi Steve, Thanx for the reply; I played around with the code a bit yesterday (and even created my own test program - listed below). >Are you sure this is where it's locked up? How do you know if running >on a real device? No, I'm not sure that's where it's locked up. Actually, from your comments below, I suspect that it's not locked up in the polling loop. {Quote hidden}> >> >> The Code is: . : >> >> bcf EECON1 & 0x07F, WREN ; Disable the EEPROM From Writing >> bcf STATUS, RP0 >> return >> > >Assuming that your equates are all OK... I've reviewed the produced code and all the values look okay. > >I can't see anything wrong with this code fragment except perhaps a >(harmless) typo on the third last line. Thanx for pointing out the Typo (I've fixed it in the snippet above). >It could be an interrupt >routine going haywire. You enable interrupts prior to testing WR going >low. If the interrupt routine accidentally clears RP0, or assumes that >RP0 is cleared and thus messes with the wrong registers, then you'll be >in strife. Yah. Thanx for pointing that out. I will change the code so that RP0 is reset in the interrupt handler. The interrupt handler itself changes values in PORTA and PORTB to drive the LED displays. So, there is a good chance that this would get screwed up. >It's a matter of taste, but I prefer to turn off WREN immediately after >setting WR, especially if interrupts are enabled while waiting for >write completion. This will prevent accidental re-setting of WR which, >although the manual doesn't say much about it, could extend the write >cycle indefinitely. Thanx for the hint. I'll try that in my test code tonight. >Trace it through to see why it is executing so quickly. What precisely >is it that is taking only one cycle: is the tight loop bailing out >immediately? Right now, I am just single stepping the code. Is there any other way I should be tracing what's happening? >After resetting the device, does the EEPROM location read 0x55 or is it >junk? To test out the EEPROM write (ie make it very simple to understand what was happening), I created the following code. In terms of Hardware, I have attached a 4.7K Resistor from Vdd to _MCLR with a momentarily on switch pulling _MCLR to ground and a 4.7K Resistor from Vdd to RA0 with a momentarily on switch pulling the pin to ground. I put on 8 LED's with 220 Ohm Resistors to Vdd on all the PORTB bits to show what's going on. title "Test8 - Test Writing to the EEPROM." ; ; This Program Reads the Value in EEPROM Adress 0, displays it on 8 LEDs, ; waits for a button Press (at RA0) and then shows the value in EECON1 on ; the LEDs. This program is to help explain why I'm having trouble writing ; the EEPROM. LIST P=16C84, R=DEC errorlevel 0,-305 INCLUDE "d:\picstart\p16cxx.inc" ; EEPROM Registers Chk EQU 0 ; Check Value for Reading __CONFIG _CP_OFF & _XT_OSC & _PWRTE_ON & _WDT_OFF org 0 clrf PORTB ; Set PORTB to All Output bsf STATUS, RP0 clrf TRISB & 0x07F bcf STATUS, RP0 movlw Chk ; Read "Chk" in EEPROM movwf EEADR bsf STATUS, RP0 bsf EECON1 & 0x07F, RD bcf STATUS, RP0 movf EEDATA, w xorlw 0x0FF ; Display the Value in "Chk" movwf PORTB xorlw 0x0FF btfsc PORTA, 0 ; Wait for Button Press to Continue goto $ - 1 addlw 1 ; Increment the Read Value bsf STATUS, RP0 ; #### - Changed to See if WREN Set Earlier bsf EECON1 & 0x07F, WREN ; will Fix the Problem. bcf STATUS, RP0 movwf EEDATA ; Write the Incremented Value Back into the movlw Chk ; EEPROM movwf EEADR bsf STATUS, RP0 movlw 0x055 ; Put in MChip Specified Code Sequence movwf EECON2 & 0x07F movlw 0x0AA movwf EECON2 & 0x07F bsf EECON1 & 0x07F, WR Loop ; Display EECON1 Status movlw 0x0FF xorwf EECON1 & 0x07F, w bcf STATUS, RP0 movwf PORTB bsf STATUS, RP0 goto Loop end This program initially shows the value in "Chk" and then waits for a button press to continue on with the write. I put the Button on _MCLR to allow me a quick reset and see what was actually written. When I run this code in MPLAB, It works exactly as expected - except for how quickly the EEPROM is written (at the "bsf STATUS, RP0" instruction, EECON1 changes to show that the write has completed by setting the EEIF and resetting WR. WREN is still set as well). I have created a small stim file which goes through two cycles to show that the EEPROM is getting written. When I first ran the program on Hardware, along with WREN and EEIF being set, I also got WRERR being set. But, when I re-ran the program (ie hit reset), the value I read from EEDATA was correct. So I thought it was running okay despite the WRERR. Now, when I turned off the power to the PIC and left it for a five minutes and re-ran the program, I found that the program didn't have the Value in EEPROM I was expecting (ie the last incremented value). Re-reading the Datasheets for the EEPROM (Chapter 7 of the 16C84 Datasheets), I see that EEADR and EEDATA don't change on an error and I guess the charge is sticking around inside the PIC for a few minutes (I did turn off the power, remove the PIC from the proto-board and then put it back in and found that often the value would still be in EEDATA - it really took five minutes for the charge to dissapate). Does anybody have any idea on what's causing the WRERR? I'm running the PIC at 1 MHz (it's a 4 MHz part) on a Protoboard. It almost seems like I'm not setting the PIC up properly for an EEPROM Write. Thanx, Myke > > Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

Hi Folks, More on the Saga. Using the Code, below, I've played with it a bit and learned a few things. First, the "WRERR" signal gets asserted when the "WR" Bit gets Reset. This seemed to happen roughly 9 msec into the program (according to the timing loop that I am using). Secondly, I have tried a bunch of different changes (PWRTE Off/On, WDT Off/On) to try and find where the problem was, with no luck. Where i did get some luck was putting in a .670 second delay before the first read of the PIC. The "WRERR" is no longer asserted when "WR" is reset, but the data doesn't seem to be getting put into the EEPROM. The data changes in an unexpected manner (ie Bit 1 in the EEPROM *never* seems to get set). Am I missing some parameter to allow EEPROM Reads and Write? I've gone over the datasheets repeatedly, but I'm not having any luck. Does anybody have any working code they can post? Thanx, Myke Here is the code that I am *currently* using: {Quote hidden}> > title "Test8 - Test Writing to the EEPROM." >; >; This Program Reads the Value in EEPROM Adress 0, displays it on 8 LEDs, >; waits for a button Press (at RA0) and then shows the value in EECON1 on >; the LEDs. This program is to help explain why I'm having trouble writing >; the EEPROM. > LIST P=16C84, R=DEC > errorlevel 0,-305 > INCLUDE "d:\picstart\p16cxx.inc" > >; EEPROM Registers >Chk EQU 0 ; Check Value for Reading > > __CONFIG _CP_OFF & _XT_OSC & _PWRTE_ON & _WDT_OFF > > org 0 > > clrf PORTB ; Set PORTB to All Output > bsf STATUS, RP0 > clrf TRISB & 0x07F > bcf STATUS, RP0 > .667 sec Delay here with a write to PORTB with 55/AA to show the program is working {Quote hidden}> > movlw Chk ; Read "Chk" in EEPROM > movwf EEADR > bsf STATUS, RP0 > bsf EECON1 & 0x07F, RD > bcf STATUS, RP0 > movf EEDATA, w > > xorlw 0x0FF ; Display the Value in "Chk" > movwf PORTB > xorlw 0x0FF > > btfsc PORTA, 0 ; Wait for Button Press to Continue > goto $ - 1 > > addlw 1 ; Increment the Read Value > > bsf STATUS, RP0 ; #### - Changed to See if WREN Set Earlier > bsf EECON1 & 0x07F, WREN ; will Fix the Problem. > bcf STATUS, RP0 > movwf EEDATA ; Write the Incremented Value Back into the > movlw Chk ; EEPROM > movwf EEADR > bsf STATUS, RP0 > movlw 0x055 ; Put in MChip Specified Code Sequence > movwf EECON2 & 0x07F > movlw 0x0AA > movwf EECON2 & 0x07F > bsf EECON1 & 0x07F, WR >Loop ; Display EECON1 Status > movlw 0x0FF > xorwf EECON1 & 0x07F, w > bcf STATUS, RP0 > movwf PORTB > bsf STATUS, RP0 > goto Loop > > end Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

> From: myke predko <.....mykeKILLspam@spam@PASSPORT.CA> > [cut] > Am I missing some parameter to allow EEPROM Reads and Write? I've gone over > the datasheets repeatedly, but I'm not having any luck. Does anybody have > any working code they can post? > [cut] Sure, but try this first... I have used code very similar to yours and it works just fine. If WRERR is being asserted, perhaps there's something wrong with your power supply. Maybe it's just out of spec or it dips when loaded by the current required for EEPROM write. This is 'small', but large by normal PIC standards. Failing that, perhaps your EEPROM is worn out. Since it will take thousands of write cycles per word this is unlikely unless you pulled a 2nd hand chip, or have been really thrashing the location in your testing. Try using a different EEADR and see if the same problem occurs. Also, to check basic device operation, you should try burning the EEPROM from your programmer and see if it reads back OK. This is done by org 0x2100 ; Microchip std. de data,data,data,... ; Your test data bytes in your source code, and setting the appropriate options on your burner. Regards, SJH Canberra, Australia

Myke: I had a similar problem programming and reading the EEPROM data in a 16C84 using PICstart Plus. In response to my earlier post here, Darrel Johansen verified that there is a problem when using Simulator mode in MPLAB with the PICstart Plus. Here is the response that I recieved then. I don't know what the status is regarding a fix to the problem. Brent ---<Included Mail>--- >Subject: Picstart Plus Data EEPROM programming >Author: Brent Miller <@spam@millerKILLspamHAL.COM> at Internet_Exchange Date: >6/23/96 3:50 PM >I have been trying, without much success, to program the data memory >in a 16C84 using the new Picstart Plus programmer under MPLAB. >EEPROM data programming is supported by the Picstart Plus, at least >according to the menus. What I have seen is that the data that gets >written is always 'FF', regardless of the data in the source file. Brent, We've gone through testing again on the 16C84 and you've identified a true bug. It appears that if you are in Simulator mode, the '84 data memory is not read/programmed in PICSTART Plus. If you go to Editor Only mode, you can manually enter data in the EEPROM window and it will burn/read correctly. We have found a way to get this to work correctly. If you follow this sequence, this seems to work: - Select Editor Only mode - Enable PICSTART Plus - Select 16C84 for the PICSTART Plus - Open your 16C84 Project and Rebuild. - Program the 16C84. I'll keep you and the PICLIST posted as soon as we have fully investigated, fixed, and re-tested. Thanks for the feedback. Darrel.

Just to update, it's been a frustrating, confusing, but rewarding weekend. I managed to spend an hour or so each day to work on the problem of *me* being able to write to the EEPROM in the C84. I'm saying *me* because it's obvious that it's something I am doing. Although I have learned a couple of things along the way: 1. For repeated writes to EEPROM (different) addresses, I found that you have to clear EECON1. I haven't gone through and really understand what is happening, but I could not get repeated writes to EEPROM working unless I cleared EECON1. Actually, I found that unless I did this, I would get the "WRERR" Bit set after a single write (no other operations) - but that the write would take. 2. MPLAB/PICStart Plus DOES write to EEPROM when it is in "Simulator Mode". It just clears (writes all 1s) in the EEPROM. The "EEPROM Memory" of MPLAB is not written to when you Assemble in MPLAB in "Simulator Mode". 3. In MPLAB "Editor Mode", "Program Memory" is NOT written when you assemble. This means to program a C84 with both Code and EEPROM data you have to: 1. Go into "Simulator Mode" 2. Do a "Build All" 3. Program the Part (Select *Everything* in "Program/Verify") 4. Go into "Editor Mode" 5. Do a "Build All" 6. Program the Part (JUST SELECT "EEPROM" in "Program/Verify") 4. You have to be in "Editor Mode" to be able to read the EEPROM. So where am I now? I have a dummy program which does what I want my final program to do - Read, Read, Write, Write, Write, Read. Which is looking at two check Bytes for AA/55 and if they aren't there, puts them, along with a 0x80 in for the Calibration Value (I'm doing a Digital Thermometer). Now that it's working, I'm looking for differences between it and the non-working code. When I find it (hopefully tonight), I'll pass it along. Thanx to Brent for sending me the original note. Myke {Quote hidden}>Return-Path: <RemoveMEowner-piclistTakeThisOuTMITVMA.MIT.EDU> >X-Sun-Charset: US-ASCII >Date: Wed, 31 Jul 1996 10:28:12 -0700 >Reply-To: pic microcontroller discussion list <spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU> >Sender: pic microcontroller discussion list <TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU> >From: Brent Miller <RemoveMEmillerTakeThisOuTHAL.COM> >Subject: Re: Help With 16C84 EEPROM >To: Multiple recipients of list PICLIST <PICLISTEraseME.....MITVMA.MIT.EDU> >X-UIDL: 93efe59d6615913a0262e2fdec3ac7dc > >Myke: > >I had a similar problem programming and reading the EEPROM data in >a 16C84 using PICstart Plus. In response to my earlier post here, >Darrel Johansen verified that there is a problem when using Simulator >mode in MPLAB with the PICstart Plus. Here is the response that >I recieved then. I don't know what the status is regarding a fix to >the problem. > >Brent > >---<Included Mail>--- > > >Subject: Picstart Plus Data EEPROM programming > >Author: Brent Miller <EraseMEmillerHAL.COM> at Internet_Exchange Date: > >6/23/96 3:50 PM > > >I have been trying, without much success, to program the data memory > >in a 16C84 using the new Picstart Plus programmer under MPLAB. > > >EEPROM data programming is supported by the Picstart Plus, at least > >according to the menus. What I have seen is that the data that gets > >written is always 'FF', regardless of the data in the source file. > > Brent, > > We've gone through testing again on the 16C84 and you've identified a > true bug. It appears that if you are in Simulator mode, the '84 data > memory is not read/programmed in PICSTART Plus. If you go to Editor > Only mode, you can manually enter data in the EEPROM window and it > will burn/read correctly. We have found a way to get this to work > correctly. If you follow this sequence, this seems to work: > > - Select Editor Only mode > - Enable PICSTART Plus > - Select 16C84 for the PICSTART Plus > - Open your 16C84 Project and Rebuild. > - Program the 16C84. > > I'll keep you and the PICLIST posted as soon as we have fully > investigated, fixed, and re-tested. > > Thanks for the feedback. > > Darrel. > > Do you ever feel like an XT Clone caught in the Pentium Pro Zone?