View previous topic :: View next topic |
Author |
Message |
jmaudley
Joined: 01 Feb 2011 Posts: 32 Location: 53
|
EEPROM seems to erase after read |
Posted: Fri Nov 16, 2012 5:42 am |
|
|
Hi,
I'm having a problem with writing and reading to EEPROM with a 16F877A.
The first read comes back as 5a (correct) but then subsequent reads come back as ff as though the memory gets wiped after read.
Checked fuses and that looks OK so officially confused now.
Am I doing something wrong? Any help appreciated.
My simplified code is as follows;
void main(void)
{
//initialise_hardware(); //include file
delay_ms (10000); //to allow me time to view first read
// Write to EEPROM memory once
write_eeprom (0x0f, 0x5a);
while(true)
{
int8 value;
//write_eeprom (0x0f, 0x5a);
value=read_eeprom (0x0f);
fprintf (com1, "%c\r",value);
delay_ms (5000);
}
} |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Fri Nov 16, 2012 6:06 am |
|
|
hmm...I'd look at the eeprom contents using MPLAB to verify the chip has the real data.
Without knowing more, you could have a 'comport' issue,faulty wiring,PC terminal program issue,quirky hardware.......
At least by reading the PIC in MPLAB you would see the 'hard' eeprom data and then debug from there,one step at a time.
hth
jay |
|
![](templates/subSilver/images/spacer.gif) |
Mike Walne
Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK
|
|
Posted: Fri Nov 16, 2012 7:21 am |
|
|
Four things.
1) Try out temtronic's suggestion.
2) The code, as offered, is not compilable, so we can't test it.
3) Use the code button, code then retains format, and is more readable.
4) No compiler version number.
Mike
It's all in the CCS forum guidelines |
|
![](templates/subSilver/images/spacer.gif) |
jmaudley
Joined: 01 Feb 2011 Posts: 32 Location: 53
|
|
Posted: Fri Nov 16, 2012 8:43 am |
|
|
Thanks for responses.
Pretty sure it's not hardware as this is a tried and tested board that is in use but programmed in another language (including EEPROM read/writes).
Have been doing lots of debugging with the RS232 output to Docklight terminal program and am also sure that's not the problem.
Compiler version is 4.128.
Checking EEPROM contents sounds like a good starting point so I will do that.
If I don't make any progress I will post compilable code.
Thanks again. Jim |
|
![](templates/subSilver/images/spacer.gif) |
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Fri Nov 16, 2012 9:02 am |
|
|
Hi,
That code should basically work, but you definitely don't want to be declaring your variables "in-line", and especially inside a While loop. Move your declaration of 'Value' to the top of Main!
Edit: I tested the code on a 16F648A device, and it works fine. It would be 'better' (more intuitive) if you changed your fprintf to this:
Code: |
fprintf (com1, "%x\r\n",value);
|
These small changes will print the hex representation of the EEPROM value which will match the way your specified the value when writing to the EEPROM. Each value will also be printed on a new line for easier reading!
John |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19365
|
|
Posted: Sat Nov 17, 2012 3:41 am |
|
|
My guess would be that you have killed the EEPROM at some point.
The first read 'succeeds' because the value is still in the buffer from the write.
I notice you now have a delay in the loop, and the write outside the loop. However I'd guess at some point you had the write in the loop, and possibly no delay?. If so, you can kill a cell in the EEPROM, in as little as 40 seconds, with repeated writes.....
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
jmaudley
Joined: 01 Feb 2011 Posts: 32 Location: 53
|
|
Posted: Mon Nov 19, 2012 2:54 am |
|
|
Swapped chip, PCB and changed power supply and it worked.
Unfortunately went back to the original set up and also got it working so I'm not quite sure what the solution was.
Thanks to everyone for there suggestions, they all made sense. |
|
![](templates/subSilver/images/spacer.gif) |
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Mon Nov 19, 2012 7:57 am |
|
|
Hi Ttelmah,
Is the destruction of the EEPROM memory cell-specific? IOW, if you damage
a single cell with repetitive writes, does it effect any of the other memory
cells?
John |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19365
|
|
Posted: Mon Nov 19, 2012 8:47 am |
|
|
On the EEPROM it is basically cell specific (though see below). This is why things like SSD's have extra memory and do a checksum on the data when it is written. If it reads back 'wrong', the hardware controller 'retires' the block and uses one of the spare ones. The better drives also perform 'wear leveling', deliberately moving where data is actually stored so that busy sectors are not continuously put back in the same place. Most of the modern chips have a much higher write life than the EEPROM in the rather old PIC involved here. It only guarantees 10K writes, while a couple of generation later chip like the 4520, raises this to 100K. The data sheet for this chip has the sensible comment:
"Depending on the application, good programming
practice may dictate that the value written to the
memory should be verified against the original value.
This should be used in applications where excessive
writes can stress bits near the specification limit."
However though cell specific, writing to other cells in an EEPROM, will effect a cell. There is a total erase/write limit, as well as an individual one. Also erasing a nearby cell, will slowly degrade the contents of other cells. This then brings the concept of 'refresh', where you rewrite the entire contents (though this uses a write life), to avoid degradation if performing a lot of erases elsewhere in the chip....
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|