• AVR Freaks

Helpful ReplyPIC32 Flash Cell Endurance

Author
Vincent44
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/09/19 03:41:47
  • Location: 0
  • Status: offline
2014/09/19 05:44:11 (permalink)
0

PIC32 Flash Cell Endurance

Hi all,
 
Apologies in advance if I am posting in the wrong section, I am new here and I still need to figure out my way around...
 
I am currently working on application that needs to store data in NVM :
-> Prior power down if user turn off the device properly
-> Periodically to still have strack of data even if the user unplug the power supply
 
The use of external NVM is impossible here because the hardware is already done.
 
The only solution is to use the internal Flash of my PIC32.
PIC32 is given for (min) 20,000 E/W cycles, which is not enough for my usage : since I need periodic saving over a long period of time, I'll need more or less 300k E/W.
 
When writing in flash, the whole page (4096 bytes) needs to be erased before. However, I only need to store a small quantity of data (+/- 20 integers = 80 bytes).
 
I am considering creating 'partitions' in a single FLASH page, on order to write at a different location at each saving (circular buffer).
These partitions will be managed by software, using a simple counter. Obviously, a backup Flash page will also be needed to keep information safe in case a writing failed.
I beleive this is more or less the principle used for the EEPROM Simulator provided by Microchip.
 
Example :
 
|--------------------------------------------------- |     FLASH PAGE START
|                                                                         |
| Partition 1 : Store data here at saving 0, 4, 8, ...   |
|                                                                         |
|--------------------------------------------------- |
|                                                                         |
| Partition 2 : Store data here at saving 1, 5, 9, ...   |
|                                                                         |
|----------------------------------------------------|
|                                                                         |
| Partition 3 : Store data here at saving 2, 6, 10, ... |
|                                                                         |
|----------------------------------------------------|
|                                                                         |
| Partition 4 : Store data here at saving 3, 7, 11, ... |
|                                                                         |
|----------------------------------------------------|    FLASH PAGE STOP

Using this 4 partitions example, I expect to multiply by 4 the number of time I can write in flash before I reach the 20,000E/W.
However, I am not sure of this, since prior writing data, the whole page needs to be erased.
My question(s) :
When FLASH is given for 20,000E/W, how should we actually count ?
Is this value for a full page, even if a single word is writen ?
Can I  erease flash as many times as want, and what actually matters is the number of Write ?
 
This idea is for sure a solution to increase the number of data writen in Flash over the timer, but I am just not sure if it is doable in a single page or if each partition should be a different page.
 
Thanks in advance.

Vincent
 
 
 
#1
Mysil
Super Member
  • Total Posts : 3324
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/19 10:56:33 (permalink)
4 (1)
Hi,
The flash partition principle you outline is similar to what is used in Microchip Data EEPROM Emulation example code, and in general is called wear leveling.
 
In DEE_emulation, the size of each data partition is fixed at one 32 bit word, and in addition to this there is a 16 bit word for each partition used to find what is wanted to get back, and for error detection.
If you write own code, you may use any partition size needed, up to the size of an entire flash page.
Also, you may do this for just 1 flash page, or alternate over several pages of flash memory.
 
In DEE_emulation, when writing, the code will search for the first partition that has not been written already. When reading, it will search from the latest partition written until the wanted item is located.
If you store only one kind of data records, some logic may be simpler.
 
About Flash endurance, Microchip has several Application Notes on the subject.
I think number of E/W cycles may be regarded as valid for each flash bit cell, but since Erase operation may only be done a whole page at a time, it may usually be number of Erase operations for each page that must be carefully limited.
 
Regards,
   Mysil
#2
RISC
Super Member
  • Total Posts : 5376
  • Reward points : 0
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/19 12:35:00 (permalink)
0
Hi Vincent,
There are several types of PIC32 which have different endurance so you must be very specific about the PIC32 which you describe. Which reference is it ?
regards
#3
maxruben
Super Member
  • Total Posts : 3301
  • Reward points : 0
  • Joined: 2011/02/22 03:35:11
  • Location: Sweden
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/19 15:52:44 (permalink) ☄ Helpfulby Vincent44 2014/09/22 01:04:14
0
You don't need to erase the page if you want to write to already erased locations in the page.
 
/Ruben
#4
Vincent44
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/09/19 03:41:47
  • Location: 0
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/22 01:00:28 (permalink)
0
Thanks for replies.

Mysil, I only have 20 (ish) integers to save, which is why I am looking for a a basic solution, not based on any library.
But that's also to get some practice on "how to save data in NVM".
With only 20 integers to save in Flash, I can split a single page into 51 parts, giving me an equivalent of 51 * 20,000 = 1,020,000 E/W, which is large enough for my application.
I've been looking for application notes concerning Flash memory, but I have to say that I couldn't find what I was looking for. I'll have a second look.

RISC, I'm working on two different boards (a master and multiple slaves), one based on PIC32MX350F256H, and the others on PIC32MX128C150F. These two PIC are given for 20,000 E/W with no specific details wether if this value is for Erase or Write (at least, on the general datasheet).

maxruben, I think your answer is just what I needed. Indeed, with partitions in a single page, I do not need to erase the whole page every time I write data.
Taking back my 4 partition exemple from the first post, I only need to clear the page when I go back to the first partition : 1 clear every 4 iterations.

From this, I guess that it's also possible to erase only part of a page.
Since erasing a page consists in writing 1s on all bits, I assume that using NVMWriteWord() with a buffer full of 1s will give the same result (for a single row of the page).
Is this correct ?
#5
ric
Super Member
  • Total Posts : 22278
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: PIC32 Flash Cell Endurance 2014/09/22 01:45:48 (permalink)
4 (1)
Vincent44
...
From this, I guess that it's also possible to erase only part of a page.

No. The definition of a page is the minimum block that you can erase.


Since erasing a page consists in writing 1s on all bits, I assume that using NVMWriteWord() with a buffer full of 1s will give the same result (for a single row of the page).
Is this correct ?

No. You can NOT write 1 bits at all, only zeroes. An erase is the only way to get the bits back to 1, which is a different operation.

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#6
Vincent44
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/09/19 03:41:47
  • Location: 0
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/22 07:26:13 (permalink)
0
Yups, you are right ric.
I've made asumption too quickly. Thanks.
#7
Jim Nickerson
User 452
  • Total Posts : 5943
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/22 07:36:56 (permalink)
4 (1)
Maybe you could preface your block of saved integers with a non 0xffffffff value to mark the beginning of a block followed by how many integers are in the block.
As you update the data write 0x00000000 to the entire block and begin anew till the entire page is used up.
When you fetch the values scan till you find the first non 0x00000000 value.
I have also used a method where I started saving data at the end of the page and scanned from the beginning of the page to find the first non 0xffffffff value.
#8
Vincent44
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/09/19 03:41:47
  • Location: 0
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/23 01:40:49 (permalink)
0
JANickerson, I am using something similar to keep track of where is the stored the latest data.
Since I am storing for how long the device has been turned ON, I can easilly find the latest partition used.

I have an additional question about FLASH usage. I have been advised to use a checksum (or a CRC) to make sure that the data I read back from FLASH is valid. I however do not see any point to this : why would FLASH be corrupted and not RAM (unless the maximum number of E/W cycle has been reached) ?
#9
Mysil
Super Member
  • Total Posts : 3324
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/23 04:48:03 (permalink)
3 (1)
Hi,
Flash and other EEPROM technology E/W endurance is not a fixed number, instead it is a statistical parameter with a lot of spread, and is also influenced by external conditions like temprature, voltage, and number of words written in each operation.
Even the minimum number of E/W cycles specified in datasheet is a statistical value with some probability of failure ( 0.3% or 1%?).
See: http://ww1.microchip.com/...en/AppNotes/01019A.pdf

Then the usefullness of a checksum or CRC may depend upon a suitable reaction when a failure is detected.

Regards,
Mysil
#10
vini_i
Super Member
  • Total Posts : 398
  • Reward points : 0
  • Joined: 2014/01/16 17:51:55
  • Location: Ohio, United States
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/24 09:31:59 (permalink)
0
so when working with flash directly it would be recommended to calculate the CRC, write the data and CRC, then read the data recalculate the CRC and see if it passes.
that way the data is stored and then verified?
#11
Nikolay_Po
Super Member
  • Total Posts : 1859
  • Reward points : 0
  • Joined: 2012/04/01 13:49:27
  • Location: Russia, Novorossiysk
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/24 09:42:47 (permalink)
0
vini_i, yes. The most hard question is what to do if the CRC wouldn't coinside?
#12
maxruben
Super Member
  • Total Posts : 3301
  • Reward points : 0
  • Joined: 2011/02/22 03:35:11
  • Location: Sweden
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/24 13:14:35 (permalink)
4 (1)
One reason to use CRC is that writes to flash could fail if it is done when power is switched off. If CRC doesn't match, you know the values in flash isn't valid. What you will do then depends on what the data is used for.

/Ruben - Replied with mobile theme - Elegant still doesn't work.
#13
Vincent44
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/09/19 03:41:47
  • Location: 0
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/25 00:13:40 (permalink)
3 (1)
In my case, I made the choice to use two pages, that I named DATA and BACKUP.
When I need to store in FLASH, I first put my variables in BACKUP. Then, I copy it into DATA.
Using this, I am sure to never end up with a blank page in case power failure just after Flash erase.
Then, whenever I want to read data in Flash memory, I first try in my DATA page. If no data is found (or if CRC is wrong), I try in BACKUP.
If again in BACKUP I am not able to get any valid data, I assume that my Flash is 'dead' and I use default values.
 
To sum up, to make sure I have secure data, I use a 'clone' of my DATA page + a CRC.
 
#14
vini_i
Super Member
  • Total Posts : 398
  • Reward points : 0
  • Joined: 2014/01/16 17:51:55
  • Location: Ohio, United States
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/25 08:10:30 (permalink)
0
could someone tell me if this idea makes sense and is doable
 
write an array in flash filled with, just for example, 5 address of places to put data, aligned in such a way that no two groups of data ever share a page. 
 
each group of data would consist of an unsigned integer write number, the data, the check sum calculated using both the write number and data. 
 
when the processor powers on it will check the write number for each of the 5 data locations and assume that the largest write number is the current data. 
 
when the processor goes to write, it will write to the next data location after the largest write number. after the write is complete the data is read back and verified. if during that process the check sum fails the address in the array is wiped to zero. that way the cell is assumed dead and will be skipped. 
 
finally if a check sum fails during a read the data address is also wipe from the array and the second largest write number is used as the backup. 
 
if all the dresses in the array are zero then default values are used.
#15
Mysil
Super Member
  • Total Posts : 3324
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: PIC32 Flash Cell Endurance 2014/09/25 09:20:48 (permalink)
4.5 (2)
Hi, vini_i
 
In my opinion, the suggestions are doable: yes, sensible: no.
My suggestion would rather be to learn to use DEE_emulation library for PIC32,
(with corrections published in this forum).
 
Application code still have to determine what to do in a error situation.
 
Regards,
   Mysil
#16
Jump to:
© 2019 APG vNext Commercial Version 4.5