PIC24 : using Flash memory to store calibration data

[avatarengineer]

My task is to store about 80 bytes of calibration information
into the Flash memory since there isn't any EErom to play with.

I've search through many many discussion threads and
haven't found a clear, "complete", and concise answer
on implementing the CCS write_program_memory( ) command.

-- I'm using PIC24EP512GP806.
The data sheet confuses me more than helps.
-- I suspect the page size is 2K (2048 bytes), is that true?
-- I wish to begin a write at a page boundary (to incur an erase) and
I can only assume there is one every 0x0800.
If program memory starts at 0x200, can I assume
that a page starts every 0x800 from 0x200 (ie 0xA00)
or that it starts at 0x800, then 0x1000, etc...?
-- Reserving an area for data, using the #org statement seems unclear
if that should use the entire page start and end address.
Shouldn't it? If a page erase occurs, that space mustn't have any program code, yes?
Funny that it's not mentioned in the Help for the write command.
-- Some sample code I've seen adds a delay statement after the write.
How long should a delay be if the write statement is invoked?
--- write_program_memory( address, dataptr, count ), the "CCS Help" defines the count as a qty of bytes.
IF I am writing 32bit data, does the command know about the 4th byte is a dummy due to 24bit addressing
and spreads the bytes while skipping the dummy byte?
or do I chop my 32bit data into 16bit Longs and make 2 writes?

As you can tell, this has been a frustrating journey. ---

It would be really nice to see a complete functional code example
instead of the dancing around the details as seen in many threads.

===

[jeremiah]

[jeremiah]

NOTES:
1. If write_program_memory() normally erases a page when the address is the page boundary, then pgm_eeprom_write() will as well. It just provides a wrapper for write_program_memory()

2. This wrapper takes away the need to specify a specific ROM address. All addresses supplied to these functions should be 0-(page_size-2).

3. This is a single page psuedo eeprom. It uses the page prior to the page that stores the FUSES statements.

4. While odd length data is allowed, odd addresses are currently not. All supplied addresses must be even.

5. The wrapper handles reading/writing zeros to the correct spaces. Your data arrays need only to have the data you want to save.

6. Again, this isn't fully edge case tested. It works on my small project.

7. It uses a RAM buffer to handle writing. There are probably better ways to do it, but this is how my current one works.

[avatarengineer]

Bless you, Jeremiah.

This looks great!

[jeremiah]

no problem.

Just remember to thoroughly test it. While it works for my PIC24 chip, yours is very different from mine, so you'll need to make sure it works correctly.

Also remember, that program memory tends to have a shorter number of write attempts to it compared to EEPROM, so don't try to write to it often.

[avatarengineer]

Thanks again;

Since I only intend to store calibration information that is entered only a few times in the lifetime of the product, I doubt there will be much wear-out.

Question:
I have 20 Float values which I will "translate" into 80 bytes for storage.
The struct { int8 CAL[80] } CALPOINTS
Would my intended code be to call
pgm_eeprom_write(0,&CALPOINTS,sizeof(CALPOINTS));
to complete the storage?

[jeremiah]

Yes that is the intended usage.

You just need to verify that writing to address 0 of the "eeprom" in program memory is correctly erasing first:

Read data from eeprom and print to screen
Increment one of the values
Write back to eeprom

Reset power

See if value read is the one stored last time after the increment. I assume it works on your chip too, but have only tested on my own.

To read back you would use:
pgm_eeprom_read(0,&CALPOINTS,sizeof(CALPOINTS));

EDIT: if you just have an array, you don't need the struct:

int8 data[80];
pgm_eeprom_write(0,data,sizeof(data));

should also work.

If you have trouble, try a simpler structure or array first and use read_program_memory() to verify the data is being written to the right spot.

[guy]

Thanks for the code Jeremiah.
Here is a more simple approach to configuration / calibration data with obvious pros and cons. I used a fixed-size RAM buffer as a copy of a Flash Memory page. It can store 64 16-bit numbers.
On startup the flash memory page is read to RAM (readFlashPage) then during runtime Reads and Writes are done to RAM (readFlash, writeFlash), and at any time it can also be written back to flash (before shutdown or optionally after every change) using flashWritePage.
The code is for PIC24FJ64GA308, write page size is 64 words and erase page is 512 words (or 2kbytes as address ranges).
* Pay attention to the addresses and data sizes when migrating to a different device.

[Orcino]

jeremiah, can you give a simple example of how to write int8 and int16 variables ?

I'm not getting.

Thanks

[Ttelmah]

One thing that has not been mentioned.

CCS do now supply a 'virtual EEPROM' driver for these chips. This uses the same system the MicroChip showed in an application note for these. It uses a minimum of two pages of the ROM memory, and emulates EEPROM, by working on the basis of holding a 'flag/counter' to say what each entry holds. This is a better driver, if only a few bytes in the configuration data need to change, since it does not erase a whole page, until it has to. As locations are 'used up', it flags them as used, and uses other locations in the same page (remember you can change any bit from '1' to '0' without having to erase - it's only when you have to change to '1' that an erase is needed). Each locations stores the 'address' being used, and the value stored at this address.

For what is being described this will be more efficient, since you can set the virtual EEPROM size to just 128bytes (for your 80 bytes), and this will then allow several writes before an erase it needed. The downside is it using two pages of ROM. So if ROM is short, don't use it.

The driver is called 'virtual_eeprom.c'.

If you #define MAX_EEPROM_MEMORY (128), then this will behave just like an external EEPROM, with 128 byte addresses.

The driver tells you how to modify the standard example program 2416.c, for testing.

[Orcino]

Thank you very much Ttelmah.

Solved my problem.

This month is already the second time you help me.

Thanks again.

[Ttelmah]

Glad to help.

Like Jeremiah, I had to write my own version some time ago, then 'spotted' more recently that CCS now did a driver, and made a point of 'remembering this' in case a version was needed in the future...