Reset generator for stm32

Storing parameters in FLASH is not easy.

• There is no way to prevent an update-of-parameters stopping part-way, leaving you with a confused set of old and new values.
• Individual location programming can only change bits from 1 to 0. To restore a bit to 1 you have to do a whole sector erase, and depending on your part, a sector might be between 2k and 64k bytes big.
• A location might be as small as a byte, but it might be 64 or 128 bits wide, again depending on which stm32 you have.

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

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.

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

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.

Are interrupts a problem during flash​ write process? Flash read write is quite slow.

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 ?