2013-06-13 10:20 PM
In old good 8-bit Architecture (AVR,PIC,...) CPU had a nonvolatile memory region to keep configuration parameters of the application that were persistent over reset. This region had a byte read/write access without erase requirement.
In STM32 I can not find a substitution to this EEPROM and thus I do not know how to keep my application configurations. Although STM32 Flash can be erased/written it is not acceptable. As to write byte I have to erase and rewrite the whole 16K segment (STM32F2). All I can think about is to use external I2C or SPI EEPROM. Are there any other suggestions?2013-06-14 12:00 AM
All I can think about is to use external I2C or SPI EEPROM.
Not bad idea if you can afford it.
The standard solution is to use EEPROM emulation, no need to erase pages frequently:http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF257897
2013-06-14 01:53 AM
Thanks.
Went over suggested file and found many interesting things but not EEPROM emulation. But there is a below file instead: http://www.st.com/web/en/resource/technical/document/application_note/CD00165693.pdf2013-06-14 02:43 AM
Ah yes, It only provides eeprom emulation software download, no application note.
I think it qualifies as website bug. It should add this link:Anyway, you don't have to use the provided firmware, you can write your own functions optimized for your specific use.2013-06-14 04:50 AM
I also was thinking about using 2 Flash sectors to implement EEPROM like memory. But thinking about 16Kx2 (STM32F2xx) of Flash memory being lost for stupid thing made me crazy.
In some document ST wrote that luck of EEPROM in silicon is an approach to make it cheaper. Maybe for F1 devices with 1K or 2K Flash pages this correct but for F2 and higher it's stupidity.2013-06-14 06:46 AM
I use two internal flash sectors for configuration data. In my apps the parameters are loaded only after a reset. Permanent changes (infrequent writes) are followed by a reset. I don't use the configuration parameters in emulated EEPROM mode.
I store two copies of the data block, one in each sector. This way I'm always guaranteed a good copy after a reset. When parameters are changes they are written to the ''A'' sector. After a reset if the ''A'' parameters are intact (good CRC) then I copy them to sector ''B'', the backup. If the last write failed, sector ''A'' has a bad CRC, then I can reload the previous ersion from ''B''. I always have at least one good sector for data. Jack Peacock