 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
| EEPROM emulation on PIC FLASH... |
 Posted: Sun Feb 15, 2015 9:45 am |
 |
|
Many of the PIC24 series doesn't have any internal EEPROM unlike many other PIC series...
I recently stumbled upon a Microchip App Data about emulating a Internal EEPROM with the program flash area.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en538000
The advantage cited are increased write life (vs writing directly to FLASH area) because of write management emulation...
Do anyone tried this solution to avoid having an external EEPROM?
Also I think the MCU hang on Flash write but I have to recheck...
What are your opinion on this method?
Worth it?
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
 |
jeremiah
Joined: 20 Jul 2010
Posts: 1345
|
|
| Posted: Sun Feb 15, 2015 3:21 pm |
|
|
It's important to understand that unless you do what the microchip note suggests (I didn't read the one you posted, but I assume it is the one that uses all free space until there is none and keeps a table to know where entries are), you cannot really use FLASH like EEPROM. You cannot individually erase bytes on most PIC24's (there are a select few that allow it). Additionally, the write cycle lifetime of PIC24 flash is way lower than standard EEPROM. You don't want to be writing to it very often at all. I use it as EEPROM only on devices where I plan to use it as a configuration data store where a configuration parameter might change every few days or weeks at most. I don't use it to log data or anything that happens regularly as the flash will not last very long. Also, you have to read and rewrite all data on a flash page if you need to overwrite one spot...even data you didn't intend to change this time around.
Here is a thread with two different methods. The one I posted is more complex but has different tradeoffs from the simpler one posted below it at the end of the thread.
http://www.ccsinfo.com/forum/viewtopic.php?t=52680&highlight=flash |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Sun Feb 15, 2015 3:31 pm |
|
|
| jeremiah wrote: | Additionally, the write cycle lifetime of PIC24 flash is way lower than standard EEPROM. You don't want to be writing to it very often at all. I use it as EEPROM only on devices where I plan to use it as a configuration data store where a configuration parameter might change every few days or weeks at most.
|
From Microchip App Data
| Quote: |
WRITE OPERATION
The routine then searches for the active page of the
EEPROM bank corresponding to the address. After the
active page is located, a read operation is performed.
To minimize the number of erase/write cycles, the value
is programmed only if it has changed |
| Quote: |
First, writing a data EEPROM address five times does
not mean five erase/write cycles of endurance were
consumed.
From the perspective of the program
memory, five writes were made to five different program
memory addresses.
These five writes will not cost any
additional endurance cycles until the page is filled and
the pack routine is called. |
1 million write cycle is pretty darn close to a real EEPROM endurance...
The code from Microchip is using wear leveling algorithm thus increasing the 1000 write cycle in the FLASH area to 1 million...
The only downside I've found is the CPU halting during write...
btw, thanks for the link 
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1345
|
|
| Posted: Sun Feb 15, 2015 4:40 pm |
|
|
my comments were on the standard flash endurance. The microchip method does indeed add effective endurance.
I was just providing options and discussing the tradeoffs on those incase you didn't need the full functionality of the microchip app method.
My apologies for any miscommunication. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Mon Feb 16, 2015 1:59 am |
|
|
I actually started writing this algorithm in CCS a while ago. Gave up, when the chip I was using turned out to have a problem with the CCS 'program_memory' routines, so had to go 'DIY'. However the code I was working on is:
eeprom_emul.h
| Code: |
//EEPROM emulation using the FLASH ROM
#define EEPROM_SIZE (64)
int8 page_buffer[1024];
int8 rom_buffer[EEPROM_SIZE];
#define PAGE_START (0xF400) //Two pages
#define ERASED (0xFF)
#define ENTRY_IDLE (0)
int1 page_live=FALSE;
int16 page_address=PAGE_START;
#ORG PAGE_START,PAGE_START+2047 {} //Reserve area
//Consider #ROM here to build initial data
#ORG default
//Logic is that the page starts erased to all '1'. Then each pair of bytes is used
//as an address and a data byte 'pair'. Addresses can be 1 to 63 (emulating 63 bytes
//of ROM). Address '0' is reserved as the flag saying 'cell used'. Reading a particular
//address, involves searching every other byte for the address that matches, then the
//corresponding byte can be read. To write a new byte involves finding the existing
//byte, then searching for an empty record (address 0xFF), writing the new byte
//and address marker, then marking the old one as 'cell used'. If a space cannot be found
//then the page is full. Sequence then is to read all the current values, write these
//to a new page, then erase the old page. Reading an reforming like this is the 'tidy'
//operation. Searches etc., are done in the RAM buffer in general.
//Get the current working page into RAM
void bring_live() {
int16 temp_word;
int8 temp_byte;
if (page_live==FALSE) {
//Find the record in the memory page - returns address
temp_word=read_program_eeprom(page_address);
temp_byte=make8(temp_word,1); //MSB is address record
//First identify which page is in use.
if (temp_byte==ERASED) {
//page is erased
page_address+=1024; //move to second page
}
read_program_memory(page_address,page_buffer,1024); //read whole page
page_live=TRUE;
}
}
//finds storage address for particular byte address
int16 find_byte(int8 address) {
int16 temp_word=0;
int8 temp_byte;
bring_live();
//Now need to search the RAM for the requested data address
do {
temp_byte=page_buffer[temp_word];
temp_word+=2;
} while ((temp_byte!=address) && (temp_word<1024));
temp_word-=1; //This is now the address in the RAM for the requested address
return temp_word;
}
//reads the byte from a specified address
int8 read_byte(int8 address) {
int16 temp_addr;
if (address>64) return 0;
temp_addr=find_byte(address);
if (temp_addr>=1023) return 0xFF; //No data
return page_buffer[temp_addr];
}
//finds the next empty storage record - address = 255 flags this
int16 find_empty() {
int16 temp_word=0;
int8 temp_byte;
int16 ictr;
int16 new_page,old_page;
bring_live();
do {
temp_byte=page_buffer[temp_word];
temp_word+=2;
} while ((temp_byte!=255) && (temp_word<1024));
//Now if temp_word has reached the end of the page, need to reform data
if (temp_word==1024) {
if (page_address==PAGE_START) {
//currently first page
new_page=PAGE_START+1024;
old_page=page_address;
}
else {
new_page=PAGE_START;
old_page=page_address;
}
//Need to write data to second page, then erase first
//sequence here is to read all 63 bytes, store locally, then write to
//second page, and erase original.....
for (ictr=1;ictr<64;ictr++) {
rom_buffer[ictr]=read_byte(ictr);
}
//Now need to clear the RAM buffer
memset(page_buffer,0xFF,1024);
//Now write the bytes to the buffer but do not transfer to ROM - note byte offset
for (ictr=0;ictr<63;ictr++) {
page_buffer[ictr*2]=ictr+1;
page_buffer[(ictr*2)+1]=rom_buffer[ictr+1];
}
//Now first 63 words are the current data, rest is flagged as erased.
//do page transfer
write_program_memory(new_page,page_buffer,128); //single page write to ROM
//Since writing to the first address, clears the entire page, do not need
//to transfer more than the first 128 bytes
erase_program_eeprom(old_page); //erase second page
//Now switch to address the new page
page_address=new_page;
//set next address to be used as immediately after current data
temp_word=128;
}
return temp_word-2;
}
void write_byte(int8 address, int8 val) {
int16 empty, current;
int16 word_to_write;
empty=find_empty(); //Find new location
current=find_byte(address);
//This must be done after finding the empty record, so that if data is reformatted
//it is the new record address that is found.
word_to_write=make16(address,val);
write_program_eeprom(empty,word_to_write);
//Now flag the old record as finished - if it existed
if (current<1023) write_program_eeprom(current,0L);
}
|
I never finished it, so may well be full of bugs, but it might help you get started on this. The chip had a 1024byte erase page.
and, yes, the whole CPU stops during the write. |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Mon Feb 16, 2015 3:29 pm |
|
|
Thanks Ttelmah for the code,
I've read many topics on the Microchip forum (more topic on EEPROM emulation than CCS) regarding this method and it has more drawbacks than Microchip want to let you know !
In this case, i'll go with a 24AA64/LC... they are dirt cheap but I'll have to share the i2c bus with other devices too...
I wonder why Microchip decided to exclude many dspic and pic24 devices from getting an internal eeprom!
IMO the most practical way, no i2c line required... all internal!
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Mon Feb 16, 2015 6:44 pm |
|
|
Would recommend you look at FRAM.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Mon Feb 16, 2015 8:39 pm |
|
|
| dyeatman wrote: | | Would recommend you look at FRAM. |
I've looked at them but it looks like RAMTRON is dead... | Quote: |
After 28 years of trying to get FRAM into the mainstream memory market, Ramtron is putting up the white flag and is up for grabs. |
Also FRAM is expensive (no longer in production??) compared to reg. EEPROM.
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Tue Feb 17, 2015 12:45 am |
|
|
First, I too like FRAM. Look at the Fujitsu versions, rather than Ramtron. Infineon, and Toshiba have also developed new versions, and with their production abilities Ramtron has suffered. Fujitsu has been the largest producer of FRAM for over 5 years.
On EEPROM, the 'silly' thing is to look at some of the very earliest PIC's. On these Microchip implemented EEPROM, by including an I2C EEPROM on the die. Has lots of production advantages, so it's surprising that they haven't repeated this on some of the later chips.
Unfortunately the internal flash memory is very inconvenient to use, and requires a lot of resources in the code for the buffers needed. The complete processor freeze when writing, kills it for many uses. I think there really is an assumption that 99% of projects will have external EEPROM if it is needed. Given that the prices of this are now so low, and with most of the later chips having multiple I2C peripherals, I suspect that Microchip really do assume that everybody will go this way, and that for them the extra cost of putting this on the die is more than the likely gain. |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Tue Feb 17, 2015 5:53 am |
|
|
Cypress bought Ramtron. A 16K Cypress FRAM costs $1.52.
Individual byte writes (no pages!!) and virtually instantaneous write speed
without the delays required for EPROM.
In addition to the other mfrs listed earlier TI also makes it.
For me, the huge difference in performance it is well worth the price
difference and it is the only thing I use in designs incorporating nonvolatile memory.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Tue Feb 17, 2015 12:55 pm |
|
|
| dyeatman wrote: | Cypress bought Ramtron. A 16K Cypress FRAM costs $1.52.
Individual byte writes (no pages!!) and virtually instantaneous write speed
without the delays required for EPROM.
In addition to the other mfrs listed earlier TI also makes it.
For me, the huge difference in performance it is well worth the price
difference and it is the only thing I use in designs incorporating nonvolatile memory. |
Seems right I've bought 5x FM24C04B 4k soic for 8$ ... expensive but I've gotta try them!
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Tue Feb 17, 2015 1:00 pm |
|
|
| The 'delicious' thing about FRAM, is that writes are as fast as you can send the data. The write life is also basically infinite. It really does make them superb for constants and data logging. Where they really work well, is on compiler versions where addresmod works properly. With these you can store permanent variables into the FRAM as easily as into the chip's own memory. Wow!... |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Tue Feb 17, 2015 5:04 pm |
|
|
| Ttelmah wrote: | | The 'delicious' thing about FRAM, is that writes are as fast as you can send the data. The write life is also basically infinite. It really does make them superb for constants and data logging. Where they really work well, is on compiler versions where addresmod works properly. With these you can store permanent variables into the FRAM as easily as into the chip's own memory. Wow!... |
Yes, I agree... no more bottleneck on EEPROM writes...
Also rated for trillions of writes...
You could write to FRAM at every millisecond at the same byte and have a life of 31 years!!! (1 trillion / 32 billion ms per year = approx. 31 years)
INSANE! 
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Wed Feb 18, 2015 3:12 pm |
|
|
| Ttelmah wrote: | | Where they really work well, is on compiler versions where addresmod works properly. With these you can store permanent variables into the FRAM as easily as into the chip's own memory. Wow!... |
Some versions are bad? I'm currently on V5... 5.042
Should I be worried?
Also did a little research on this addressmod topic...
I have to quote a reply from this thread -->http://www.ccsinfo.com/forum/viewtopic.php?p=184873
| Quote: | No, you are not. Several users have used this in the past, and 'liked' it's features, but gave up, with the repeated failures. I doubt if many have got involved with more 'non standard' types like int64 though....
I was quite interested that in part it started working again a few versions ago, but 'other things' have prevented me finding the time to investigate how 'close' it is the really working...
Best Wishes |
Still a minefield?
Thanks
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Thu Feb 19, 2015 4:45 am |
|
|
| Haven't had time to test recently. It was 'not working' for perhaps 20 compiler versions at one point.... |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
