Hi
Im using the LPC2103 MCU and I need to store some calibration data in the flash, so the calibration doesnt get lost when the system is powered off.
I know I can use IAP to do this, but is there other mehods? Not that I dont like the IAP solution, but just to know.! :-)
I guess I have to reserve some of the flash for this purpose. How is that done in KEIL?
/thomas
That is a question of where the calibration data comes from.
If the unit can compute the calibration data itself, then it is enough with a checksum to verify that the sector contents is valid.
If the calibration is performed by manually connecting to the unit, then it doesn't matter if it hangs or the power is lost. The operator will just have to restart the calibration again after the power is back.
For situations where the unit stores important accumulating information itself, I normally use two sectors, and reserve a byte or larger in each sector for the numbers n and n+1 and then some form of checksum (or normally crc32 or better) in both sectors. If I can afford a large enough variable size for n, then I can keep track of the total number of flash writes performed.
If both sectors passes the checksum test, then the sector with the n+1 value is used.
If only one sector passes the checksum test, then the other sector is ignored.
If no sector passes the checksum test, then the system either initializes itself with default data, switches to fault-safe mode or deactivates with some form of error signal.
If both sectors passes the checksum test, but one sector doesn't have the counter set to n+1, then the system normally switches to fault-safe mode or deactivates with some form of error signal.
There can be many approaches to using flash for storing data that can be changed by the application. Those approaches have their upsides and downsides. For example, some algorithm might offer better data integrity protection which would come at the cost of greater complexity (hence, harder debugging, greater code size and so on.) The problem is often referred to as 'EEPROM emulation.' There are two very nice application notes from ST on the subject.
AN2077 - EEPROM emulation with STR71x: www.st.com/.../11025.pdf
AN2540 - EEPROM emulation in STR91xF devices: www.st.com/.../13455.pdf
There are 3 approaches to EEPROM emulation described in those application notes. They are not really specific to any particular microcontroller. They can be applied to almost any flash memory device.
I should add that the algorithms in the above application notes are designed to maximize flash durability. When durability is not a concern, those algorithms are too complex.
The calibration is entered manaully by user, so if anything happen, the calibration is performed again. So there is not the biggest need for making the persisten data power fail safe etc.
I have done the data storage in the last sector, and its working great. Also added soem simple validation flag to it.
I just think it strange, that I have to erase the sector before I write the data to it. If i just re-write the secor again, without a sector erase, then data isnt stored right ?? I just have 272 bytes of data to store, but I have to write 512 bytes to the sector. ?
/Thomasw
If i just re-write the secor again, without a sector erase, then data isnt stored right ??
Normally the way flash works is like this: When you write to it, you can flip bits from 1 to 0, but not the other way around (remember, after erase you start with all 1's). Such behaviour is often used in EEPROM emulation algorithms which fill the sector gradually and only erase it when it's full.
I just think it strange, that I have to erase the sector before I write the data to it. If i just re-write the secor again, without a sector erase, then data isnt stored right ??
your flash memory's granularity is a sector size. by definition, it must be erased before you can write into it.
by definition, it must be erased before you can write into it
That might sound misleading. You can write twice (or more) to the same location in flash without erasing, but you can only reset bits in that location. Consider an example: - 0xFE - 0xFC - 0xF8 - 0xF0 - 0xE0 and so on... These values can be written consecutively to the same location in flash without erasing the sector.
"These values can be written consecutively to the same location in flash without erasing the sector."
With some limitations. The additional writes (to concatenate more information) are not 100% safe for other bits. So in some cases there are limits to the number of times you may update a sector until it needs to be erased and have all data rewritten, to make sure that all data on the page will fulfill the stipulated retention times.
The bad thing is that this information is seldom available in the datasheets.
On NXP's own forum, I saw a post from NXP tech support about NXP ARM chips. I think it was the LPC21xx chips they claimed max 13 writes to a sector until it should be fully regenerated.
I think it was the LPC21xx chips they claimed max 13 writes to a sector until it should be fully regenerated.
'Fully regenerated' meaning erased? And what is '13 writes'? Isn't a sector a few kilobytes in size? What if I write 13 bytes, can't I write more? It's all very confusing.
No. The message I read said that you could erase a sector. Then write a number of bytes to the sector. Then at a later time write some more bytes. Then at a later time write yet more bytes to the same sector.
But after having written 13 times to the sector with more and more information, you should not do any more writes before first copying the existing information to RAM and erasing the sector and then write back the information again.
This figure is not a fixed general value for any processor. It was just a number I picked up from NXP tech staff, and I _think_ it was for the LPC21xx series. I have never seen anything about it in any application notes. No application note seem to discuss multiple writes without an erase in between.
The post claimed that when doing multiple writes resulted in some electrons escaping through the barrier and after enough writes there would be a too small charge left in the written (or if it was in the erased) cells that the cell contents would not be able to keep a distinctive charge for long enough time.
But the message in question did not say that after 15 or 25 or 100 writes the information would just magically be lost. It said that NXP could not guarantee the retention time (i.e. don't expect the written information to survive for 10+ years) unless you limited the number of times to concatenate more information to the same sector without refreshing the data with a sector erase and new write.
I was a fool and didn't save the link to this post immediately, and I'm not sure I can find it again. But I'm about 95% sure that it was on the NXP forum. And the signature did post claiming to be NXP technical staff. I somehow got to the post based on other informative posts made by the same person about flash mechanics and I/O port designs of NXP ARM processors.
Mike: Yes, of course, I should have been more precise.
I think I found it:
tech.groups.yahoo.com/.../2681
It appears that on-chip flash memory in LPC2xxx MCU's has some serious limitations. I've been working with MCU's from ST and Freescale, and their on-chip flash memory doesn't have such limitations. Which is not surprising: ST is known for their advanced flash memory technology, and Freescale licenses one from SST.
Good catch. I don't think it is the same post (I think I picked up my info on the nxp or standardics forums) but the gist of the information is the same as I read.
I might be wrong when I thought they claimed max 13 writes before erasing and rewriting the sector. This post claims 16 writes.
Anyway - this is a link to keep. The information in it is very important and should have been in the procesor manuals. (Or maybe it is, for some LPC chips, but I haven't found it in the manuals I have read.)