I wish to use the MCU flash for storing non-volatile information such as tuning parameters. Is there a known 'best' policy of when to store these values...i find a few options and would like to get your view on them. a) Run a task for writing parameters to flash b) Write to flash during shutdown routine. (but what happens if a sudden shutdown happens)

Also, how to decide whether parameters should be read from flash or from the default code. Once a parameter is changed by the user (it is different from the default value), every following init will need to read those parameters from the flash...right? I want to know how the experienced folks deal with these issues?

Thanks and best regards, Vishal Sapre

  • \$\begingroup\$ What about a SAVE button/signal, may be plus a READ button/signal? Pro: User can change parameters an reset the MCU / reload the parameters if he wants to revert the changes. Parameters are only written when user thinks they are final. Con: User may forget to save parameters and upon restart the MCU uses old parameters. \$\endgroup\$ – sweber Nov 16 '15 at 12:41

There is no 'correct' answer to your question. In the end it depends on the details of the system you have and the level of performance you require. The main points to consider are:

  1. FLASH endurance. FLASH memory can only handle a certain number of writes before it starts producing errors. This can vary significantly between FLASH memory manufacturers (1000 to 100,000 writes) and EEPROM is generally even better (100,000+ writes). If you have more FLASH than you need to store your data, you can also write an algorithm to spread the writes over the unused part of the memory to increase the endurance. In the end you just have to consider how many times the parameters might need to be written over the life of your product and this will tell you whether you can simply write them to FLASH each time they change, or need to use a more sophisticated caching system.

  2. Power supply interruption. If your product has a built-in battery, then you can probably be reasonably sure that it will not get an unwelcome power supply interruption. This gives you a lot of flexibility in deciding when you should write data, and less often would generally be best to avoid any FLASH endurance issues. However many embedded systems do not have this luxury which means you have to decide how important the data is to store, and then prioritise the writing of it based on this. If it is very important then you need to get it to FLASH as quickly as possible. If it is not you could cache it and write it periodically if it has changed. Also note that you would normally need a means to determine if a FLASH write was completed successfully or interrupted by the loss of power. The normal way to do this is to have a final 'validation/checksum' byte that is only written once all the data has been successfully written. On startup, the micro can use this to ensure that the data stored is correct. You can even have a basic journalling system so that the code can wind-back to a previous data set if it detects a problem. How sophisticated your code needs to be depends on how likely it is to receive a power interruption while it is writing data, and the consequences of the data being corrupted.

Regarding the second part of your question (when to read) there is again no 'correct' answer. If performance is an issue and you have spare RAM, then the obvious solution is to buffer the values into RAM. If you don't have enough RAM or performance isn't an issue, then reading from FLASH each time is perfectly acceptable. Also note that on many microcontrollers internal EEPROM/FLASH reads have very little penalty vs RAM anyway.

| improve this answer | |
  • \$\begingroup\$ As you have mentioned in the point 1, there is an algorithm which spreads writes over a larger flash area..there by significantly increasing the endurance. Lets call each power cycle as a life...so 1 life before the power shutsdown and then 2nd life when power comes back. My concern is how to uniquely identify (with 100% certainity) whether the user had actually changed parameters during Life1 so that during the 'init' routine of Life2, the code reads these parameters from flash. Also, if there are say 50 parameters ... how to identify which ones were stored in flash and which ones were not. \$\endgroup\$ – Vishal Nov 16 '15 at 13:25
  • \$\begingroup\$ For this last one, I think just writing everything in Life1 and reading everything (based on a parameter that idenditifies storage) in Life2 is easier...but that can play havoc with endurance...if shutdowns are often...because in my case...all types of shutdowns shall be followed a flash write !! \$\endgroup\$ – Vishal Nov 16 '15 at 13:25
  • \$\begingroup\$ I was thinking, that while the controller is live, and the user is changing (tuning) the response, all writes/reads shall be from RAM, and only when a shutdown happens, we write to flash. Again when the controller comes up..it reads parameters from flash and stores them in RAM and uses that for its work. \$\endgroup\$ – Vishal Nov 16 '15 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.