Is there a better way to store calibration values?

[bschriek]

<16F15223.H> CCS compiler 5.121

I use the following code to read and write calibration values to the memory of my PIC's for years. Although it works fine can somebody tell me if a better solution is available for the modern pic's like the 16F15223?


//---------------Configuration-----------------//
#define HEF 0X0780
#ROM int16 HEF = {160,160}

struct twobytes
{
int8 l;
int8 h;
};

union prog_mem
{
int16 word;
struct twobytes b;
};


//-----------------Main loop-------------------//
struct {
union prog_mem I_cal_hef_24V;
union prog_mem U_cal_hef_24V;
}


//--------Read calibration values from memory--------//
read_program_memory(HEF,&values,2);
I_cal_24V = values.I_cal_hef_24V.b.l;
U_cal_24V = values.U_cal_hef_24V.b.l;

//--------Write calibration values to memory--------//
values.I_cal_hef_24V.b.l = I_sense_24V;
values.U_cal_hef_24V.b.l = U_sense_24V;
write_program_memory(HEF,&values,2);


Sorry for this question but I'm a hardware engineer.......

[newguy]

Not really. Two things: the address of the high endurance flash should be available using the getenv feature so that you don't have to look it up yourself. Second, I always guard writes to memories that are either slow or can wear out (or both). I always read the contents of the memory first and only write if the value is different than what I intend to write.

Other than those minor nit picks, you're doing it right.

[Ttelmah]

From the description, it sounds basically right. Obvious comments apply
about keeping the number of cycles down, but assuming this is rarely
done, the life of the HEF would be great.
There are 'caveat's' if you want to move later to chips like a 24F, since
on these the program memory is not contiguous as it is on the 18F.
Also you need to be aware that the processor will basically stop while
this write is being done. Could cause some problems.
Doing it as you do with the ROM declaration, is actually probably the
tidiest way of doing this.
Also obviously you have to be aware that the whole page gets erased
when you do this. so careful what else you store in this area. You
could expand the ROM statement with dummy bytes, to ensure that
nothing else gets put into the page.

[bschriek]

Thank you for your explanation last time.


In the datasheet of the pic 16F15223 I found:
Flash Memory Cell Endurance = min 10K
This value agrees to the re-wite cycles of my Read/Write code right?


But what if I want to re-write the values more than only once.
Say 20.000 times during the lifetime of my apparatus?

[temtronic]

I looked at the PIC datasheet, didn't see a maximum so...

time to cut code !

simple 20,000+ loop where
you write a known value(say 0x55) to a location, read it back, display both, then write another value( say 0xAA), read it back, display both.
obviously stop the program if the read back data <> written data

[gaugeguy]

If you feel you may exceed the minimum erase/write life then you need to have something in place to deal with a failed memory location when it occurs.
store in redundant locations, use CRC or checksum, implement ECC (error checking and correction), fall back to default values, ...

[Ttelmah]

Forget read/write.
Read cycles do not use lives. It is only write cycles that use lives. Also
you generally only use lives when a value changes. You can make sure
here by testing the value and only writing when it changes,
Honestly 10000 cycles is a huge amount. If you have a calibration that
changes twice a day, this would give a guaranteed over 13 years. However
if this is something that needs to change much more frequently than
this, you need instead to consider alternative solutions like an EEPROM,
or something like PRAM. Has the unit possibly got a clock chip?. If so,
these often have battery backed RAM storage, that is much more suited
to anything that changes much more frequently.
You can't test it as Jay describes, you need to be writing repeated changes
until it fails. So perhaps 0xAA, then 0x55, and repeat till it fails. However
this only gives the fail point for a single chip. So really proves nothing.
The life will also change with temperature and supply voltage. A flash cell
can also be lost if there is any radiation source nearby, or by a cosmic
eat hit, but these are very rare.
Look at the virtual EEPROM driver. This uses an alternative approach.
Uses a couple of pages of the memory, and stores both the value, and
it's address. Then when a value is changed, flags this value as not in use
and advances to another cell in the page. It only erases the page when
all the cells in the page have been used. This results in the effective life
rising massively (page size/number of values required) times, but is
much more complex and uses a lot more space.