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
If you are going to store the data in the flash, then you basically have two options:
- have the factory fill the board with app + config when producing the board. - use IAP to write the configuration at a later time.
Check what sector sizes the processor has. If the last sector is of a reasonable size, then just open the project options and specify a smaller RAM to hide one or more sectors at the end.
If the end sectors are too large and you have smaller sectors at the beginning or in the middle then you can use the scatter file to reserve a gap in the middle.
Hi,
back in the past usual way to store calibration data was external EEPROM so that would be one way.
Other way would be IAP that you mentioned (IAP is short for In-Application Programming).
So, yes you have to reserve one or more sectors (as when you want to store some data over existing you will have to erase that sector first), and write your procedures for erasing and programming the flash. These routines will have to run from RAM while you are erasing or deleting flash.
So for internal flash only IAP is the way.
Thanks for the replies... I think I will use IAP. An external EEPROM isnt an option, because the cost must be kept down :-)
So I will reserve a sector and then use IAP to store my data there.
Im using hte LP2103 and I can see that it has 8 sectors. They are 4 kB which is more then enough.
Sector Size (kB) 0 4 0x0000 0000 - 0x0000 0FFF 1 4 0x0000 1000 - 0x0000 1FFF 2 4 0x0000 2000 - 0x0000 2FFF 3 4 0x0000 3000 - 0x0000 3FFF 4 4 0x0000 4000 - 0x0000 4FFF 5 4 0x0000 5000 - 0x0000 5FFF 6 4 0x0000 6000 - 0x0000 6FFF 7 4 0x0000 7000 - 0x0000 7FFF
So i just change the ROM range in project options from 0x0 - 0x8000 to 0x0 - 0x7000 ? This would reserve the last sector?
/Thomas
Yes, that is enough. Decreasing the ROM size in the project will make sure that the linker generates an error if your program gets too large to fit into the remaining sectors.
That would be unsafe. You need at least two sectors if you value your data. With only one sector, you have no way of ensuring that your data aren't lost if power fails in just the wrong moment.
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.