2019-12-29 03:53 AM
Hi,
I have a flash corruption trouble with stm32f103 mcu. While i was reading topics, i have found that a reset generator must be used on system for avoiding flash data corruptions. My device has lots of parameters on stm32 flash, sometimes those data can be erased or corrupted, so my device can not be restart again. Is the right way to eliminate this problem using reset generator ? What do you think about the solution ?
2019-12-29 04:57 AM
Storing parameters in FLASH is not easy.
ST wrote an application note AN2594 https://my.st.com/content/ccc/resource/technical/document/application_note/ee/ef/d7/87/cb/b7/48/52/CD00165693.pdf/files/CD00165693.pdf/jcr:content/translations/en.CD00165693.pdf which showed a way to emulate EEPROM with at least two sectors of FLASH, so that no matter when things were interrupted, you could recover the emulated-EEPROM either before or after the latest write.
This could be a basis for your storage solution, but it does need some thought. For example if you need to store a URL, and things stop abruptly half-way-through updating this URL, you probably want to recover the whole old URL not a string containing the first few characters of the old URL and subsequent characters of the new one!
I have not known a write to fail, but it could do so if power is lost or if other parts of the code cause a crash.
Yes you'd want to go to a known condition if you decide the stored parameters are no good (your reset generator perhaps). But again you need to think what you want this state to be. Ideally you want to be able to reprogram good values into the FLASH. But (depending on your application) you might still want to prevent an attacker from getting into your system.
There is no easy solution. But I hope I have given you some things to think about to help you find an appropriate solution for your problem.
Regards,
Danish
2019-12-29 04:59 AM
Perhaps you need to understand the nature of the problem better?
Are you writing or updating the flash all the time, or doing so during initial start up? Is the system battery powered, or use a supply that ramps slowly or inconsistently?
A POR circuit that thresholds the minimally viable supply voltage and holds for several hundred milliseconds would provide some consistency.
2019-12-29 08:11 AM
In fact , i am not writing or updating the flash all the time, i do this when the power drops. There is only dc power supply and buck converter for embedded system. I am using an input pin of STM32 mcu for sensing whether the power exists or not, if it drops ,i am writing some data to flash area( first unclocking flash, erasing, writing and locking flash again). This works clearly, but sometimes when i give power supply, the system can not start and when i check the flash sector on which parameters are hold, i saw that parameters value changes to 0xFF. There was an article about this problem, but i am not sure about the solution. Please check the link below and give your advises. Thansk a lot.
https://www.digikey.com/Site/Global/Layouts/DownloadPdf.ashx?pdfUrl=A2429D3A9FFB4A08A09DB0D8A87FB8A6
2019-12-29 12:49 PM
Flash ending at 0xff could be a symptom of the erase happening, but not all of the write(s). As if power died sooner than you were hoping.
How much margin do you have between worst-case unlock-erase-program-lock time and how long your power-supply-voltage will hold up after the power-loss is detected?
Is loss-of-power detected by an interrupt or do you have to poll the sense pin?
What happens with a brown-out, where power falls low enough to trigger your save-to-FLASH code, but never so low as to reset the micro?
What about if power comes up for a short time and then dies again? There could be a few such occasions when plugging in mains power.
Things would be easier if you could arrange to have two sectors of FLASH and read from the later of the two - provided it passed a checksum. And then you’ll know to write to the other one on loss-of-power.
2019-12-30 12:14 AM
Are interrupts a problem during flash write process? Flash read write is quite slow.
2020-01-07 10:28 PM
Hi @Community member @Danish
I have noticed a strange case which is about stm32 mcu. When i cuttoff the power supply of my board and plug it again, my board could not work again. Then i connect my stm32 to stlink utility and i have tried to read the memory region of 0x0801B000 adress, but stlink utility gives "Address out of range" error. My firmware uses this adress when there is no problem. What is your advises ?