EEPROM seems to erase after read

[jmaudley]

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);
}
}

[temtronic]

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

[Mike Walne]

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

[jmaudley]

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

[ezflyr]

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:

[Ttelmah]

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

[jmaudley]

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.

[ezflyr]

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

[Ttelmah]

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