How to save a variable in non-volatile memory?

[Marco S]

Posted on September 04, 2017 at 09:49

Hello,

I'm using a STM32F091VBTx microcontroller and for the application I'm implementing I need a variable to be constantly updated and it must be stored in a non-volatile memory in order to keep its value even if the microcontroller resets. I've found AN2594 about EEPROM emulation, but the functions described there are not available for the microcontroller I'm using. Should I use the functions provided in the stm32f0xx_hal_flash.c file? If yes, I would like to know if there is a demo software for this or if there is any other method to update values in a non-volatile memory. Thanks. #stm32f091vb #variable #non-volatile #memory #eeprom-emulation Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Eugene Solo]

Posted on September 08, 2017 at 10:13

wow. Thats good to know. Usually im using only stm32F devices, not L

probably,  in some o my next project i'll migrate to L series, 6k is more than enough

[waclawek.jan]

Posted on September 08, 2017 at 10:39

Correct me if I am wrong: the erase granularity of EEPROM in L0 is word (32 bits) and, what's more important and a potential showstopper, it does not allow fetching (i.e. run program from FLASH) while writing (which takes 3.2ms or 6.4ms)

2.  If the write operation uses a Single programming operation or a Multiple programming

operation (half page) and all addresses/data have been sent to the memory interface,the read is put on hold and will be executed when the write operation is complete. It isimportant to emphasize that, during all the time spent when the read waits to beexecuted, the master is blocked and no other operation can be executed until the writeand read operations are complete.

A minor but surprising fact is that erased state of FLASH/EEPROM in L0 is 0.

JW

[AvaTar]

Posted on September 08, 2017 at 11:54

A minor but surprising fact is that erased state of FLASH/EEPROM in L0 is 0.

I have seen this feature in MCUs of other supplies, especially the 80251 compatible XMC series from Infineon.

That makes me wonder if this 'special' erase state (perhaps only inverting drivers) is a must-have or want-have requirement of the automotive industries.

[Marco S]

Posted on September 08, 2017 at 13:41

I'm using `eeprom.h` and `eeprom.c` unmodified. The base address of page 0 of flash memory is 0x08000000 both in the specification of the micro controller and in `eeprom.h`. As virtual address I'm using 0x5555. How can I ensure that the target address is not occupied by my code? According to the datasheet addresses between 0x00000000 and 0x20000000 are used for code and the flash is between 0x0800000 and 0x8040000, the variable should be saved within the flash memory, right? I'm using Atollic 8.0 and I'm calling `EE_ReadVariable` and `EE_WriteVariable` functions from the main function.

[Brian TIDAL]

Posted on September 08, 2017 at 13:44

Hi Eugene,

ST-MCU-FINDER can be used to explore the STM32 portfolio and find product that will fit your needs. For example, you can search products with a certain size of eeprom: you'll find STM32L0 and STM32L1 products.

ST-MCU-FINDER feature is included in latest STM32CubeMX.

Regards

Bruno

[Dan Mackie]

Posted on September 08, 2017 at 15:27

Clive One’s comment to me was essentially look at your .LD file, and position your flash area using that. If you look at a map file that is date and time stamped as matching a build time of your image, you should see what locations are occupied by what things. Then pick an area in the flash that you can work with, and make a .LD file that Atollic will use and not clobber. Make your eeprom.h base and length equates to suit. With all the negative comments about flash problems, I am going to test the battery backed RAM, and see how that works. I have been using battery backed SRAM for about 25 years, with no problems. Mind you, I had 64k or 128k to play with, not just 4kb. Sure, it takes a battery, but an update to SRAM takes microseconds, not milliseconds, and as a result does not fail because it takes too long at power fail time. Having a 691 power controller did not hurt either.

________________ Attachments : ~WRD000.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HySK&d=%2Fa%2F0X0000000b7u%2FtwITerUoMJBQ5R48e8ArzFtCbmf7bNGqHCw0dQzQquM&asPdf=falseimage001.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HySF&d=%2Fa%2F0X0000000b7s%2FL8FxDAypVguAyDGNeD73fmcLI3SlQI7nhHzZvfULToE&asPdf=false

[Marco S]

Posted on September 08, 2017 at 18:06

I have verified the map file. It seems like my program uses addresses from 0x08000000 to 0x08003970. So what you mean is that in the

`

eeprom.h` file I should modify the base address of the Flash sectors with addresses beginning after the end of the space used by my code, right? And then, I must modify the linker script file to indicate the range of addresses I will be using, could you please tell me if is this right? By the moment I can't use an external RAM.

[Dan Mackie]

Posted on September 08, 2017 at 19:40

Yes, those are exactly the concepts. Don’t know if your STM product has embedded SRAM. The 429 I am using

Does have 4kb of embedded sram, and I am about to experiment with that.

Dan

[Eugene Solo]

Posted on September 08, 2017 at 20:00

i guess each MCU from STM32 family has embedded SRAM

[Tesla DeLorean]

Posted on September 08, 2017 at 21:49

Probably because EEPROM is either physically larger or slower, if it were magically better than FLASH we'd be using it instead. Likely less compatible with the silicon process in use.