STM32 with EEPROM

[MehranMsba]

Posted on March 31, 2015 at 17:19

Why doesn't ST embed an EEPROM in STM32F4xx or STM32F1xx series?

Thanks.

[jpeacock]

Posted on March 31, 2015 at 19:26

The F2, F4 and others now have a 4KByte backup SRAM area as part of the RTC and backup power domain.  In some ways this is better than EEPROM since it is real SRAM and doesn't require erases or slow writes.  It is persistent across power off or resets.

EEPROM cells are large compared to the SRAM memory and would take up die space better used for other functions.  Worst case you can always attach an EEPROM with I2C or SPI, but you should look at the backup SRAM option as it does offer more flexibility. I've used it with a 10F backup supercap, holds the contents (and powers the RTC) for three weeks on an F405.  It's proven to be reliable and can quickly save a lot of information just before power down.  If you need long term store, combine it with one of the smaller internal flash pages, using the SRAM as a fast buffer with a lazy write every so often to a 16KB flash page.   Jack Peacock

[MehranMsba]

Posted on April 01, 2015 at 11:12

Thank you.

I want to continue this topic to give more information about this cause and available solutions.

[AvaTar]

Posted on April 01, 2015 at 11:41

... with a lazy write every so often to a 16KB flash page.

And translate ''every so often'' as ''as few as possible''. Flash has a limited number of erase/write cycles, 10k in most cases. This applies to EEPROM, too, as this is technologically the same, except with byte-wise erase/write access. When writing to EEPROM/Flash from you application regularly, better check if the device can sustain your write rate over the expected life time.

[MehranMsba]

Posted on April 01, 2015 at 13:11

I read this in 

http://stm32f4-discovery.com/2014/12/library-45-interface-backup-sram-on-stm32f4/

 :''

These MCUs have internal 4-kBytes of SRAM. It is on location where if you read “too much�? you can make a

HardFault

error and this is something you don’t want. So be careful when you are doing with this ram.''so,We can't read it too much, It's a RAM and RAM must have good access for read and write, Can't we read it too much!? what's about write operation?

[waclawek.jan]

Posted on April 01, 2015 at 13:32

I read this in 

http://stm32f4-discovery.com/2014/12/library-45-interface-backup-sram-on-stm32f4/

 :

''

These MCUs have internal 4-kBytes of SRAM. It is on location where if you read “too much�? you can make a

HardFault

error and this is something you don’t want. So be careful when you are doing with this ram. WHAT??? JW [EDIT] I think I got it, the point might have got lost in the translation (the author of those pages is not a native English speaker): he meant, ''you should not read beyond the size of backup RAM''.

[MehranMsba]

Posted on April 01, 2015 at 14:31

OK. you aretrusty person. I follow your sight.

Can we use BKPSRAM with specific address for compiler? for example use these codes: Keil Scatter File:

...
RW_IRAM3 0x40024000 0x00001000 {
.ANY(BKPSRAM_DATA)
}
...

Work code:

int

StableData __attribute__((section(

''BKPSRAM_DATA''

)));

I see in map file that this variable marked RW types,It's not ZI, that's mean we can use it without compiler Zero initializing problem.Is my notion true?

[Tesla DeLorean]

Posted on April 01, 2015 at 15:11

You'd be better managing it as a structure, and casting a pointer to it. Use signatures and checksums to confirm validity, and load defaults.

[MehranMsba]

Posted on April 01, 2015 at 18:19

Thanks clive.

so,It's true but I am worry about Data Alignment and direct access to BKPSRAM from compiler.I have another question about EEPROM emulation in F4 series.I use latest flash pages in F1 series(2kB size) as eeprom,but I can't allocate two 128Kbyte Page size for 10 byte in F4 series! (I can't find EEPROM emulation for F4 series,I change codes from F1)first pages is good but application code in it. what's the solution?

[Tesla DeLorean]

Posted on April 01, 2015 at 18:53

The first 4 pages are 16KB, you'd use the first one for a loader, and two of the others for the EEPROM emulation.

You could also make a sparse image, ie one with a 32KB hole in it, using linker scripts or scatter files and directing vectors and other content to the first page(s), and the majority of the application to the higher block of pages.