EEPROM on the H7xx would be nice

[n2wx]

I'm not sure how many H7xx applications deploy without EEPROMs. Everything I've touched in the last 5 years in the F3xx and H7xx line needed an EEPROM for the usual customer side configuration persistence requirement. My customers prefer to take the BOM hit for an external EEPROM like the 24C256 or even the weird PCA9500 multiuse I2C device (4 byte pages!) rather than setting things up to possibly exhaust flash words should firmware lose its mind and exhaust the flash area in seconds when used as an EEPROM substitute.

I'm sort of afraid to ask for new things that may tend to break old things but it'd be cool if ST would add a small true EEPROM to the device, maybe not the value line but for the more premium parts with more oomph. 256 bytes should be enough and it's a product ST already makes so....

[waclawek.jan]

#STM32-Wishlist​ 

[berendi]

If the configuration is not expected to change every day, then sacrificing two flash pages would be adequate. If there are no two pages to spare, you should consider adding some external memory anyway for future firmware growth.

If the firmware loses its mind and uses up the 10000 erase cycles, it can as well exhaust 10^6 erase cycles of a proper EEPROM in a couple of minutes.

[n2wx]

I have oodles of surplus flash. Enough I could include four copies of the primary program, a DFU bootloader, and images of everyone in the department along with PDFs of their resumes. Should I use flash instead of E^2 I'll need to distribute one of those resumes. It's just the way it is.

[RMcCa]

Seems to me that if the software could "lose its mind" and exhaust a flash sector or 2 you have larger problems. Pay attention to brownout and reset states. Also could the watchdog prevent this sort of runaway?

I've had good luck using 2 sectors on a F7. Blocks of configuration data are written sequentially to a sector with the code scanning the config flash at boot and reading the most recently written block. When the sector is full, copy the latest config block to the other sector and erase.

[n2wx]

> Also could the watchdog prevent this sort of runaway?

Perhaps. A windowed watchdog with tight timing. I think we've all used the two sector strategy.

[Tesla DeLorean]

I think the issue has been geometry/process related, and then testing to assure IC meets published specs.

Using FLASH here, use a couple of sectors, journal the structure, require user interaction in changing configuration parameters, likely to lose wrist to carpel-tunnel before the IC fails.

[n2wx]

I haven't tried journaling (with deltas?), just doing the naive obvious multi sector approach and using the one with the highest sequence number that's not corrupted.

[n2wx]

As attractive as using extant flash is that is not an option. It's either a) an EEPROM on the part or b) an EEPROM as an additional BOM item. Option C does not exist in a world where I keep my job.

[berendi]

There are some series like STM32L1 where there is some on-chip eeprom. ​Looking at it closely, it turns out to be just eeprom emulation on flash, implemented in hardware.

​

Which option would be that?​

[n2wx]

That's a good question. I think the EEPROM emulation has EEPROM like attributes (pages with millisecond-scale write times for ex) that look enough like a real EEPROM I'd be comfy arguing either way. Just glancing at the manual the L1 is superior to a standalone EEPROM since it requires unlocking and has ECC, both features missing from an acceptable standalone 24C256 actual EEPROM.

Another solution that would have worked and I argued for was to use a supercap and the SRAM. Talk about even faster ways to lose data, but at least no risk to the executable. I figured if the 1F supercap was perfect I could count on multi year backup. I didn't need that much. But I got shot down.

[waclawek.jan]

> I figured if the 1F supercap was perfect I could count on multi year backup.

CR2032 is perfect in this regard. If you have to maintain real time, using backup SRAM is then free (as in free beer).

JW

[Uwe Bonnes]

CR2032 imposes transport restrictions, so it needs to be considered carefully.

Using SRAM and having some power reserve and early power failure warning to flash SRAM to dedicated page could also be an option.

[n2wx]

I loved doing stuff with the button batteries - takes me back to the standalone SRAM in the 90s on z80s! - but like you mentioned they're all sorts of shipping issues with them nowadays so I don't bother. It's where the supercap comes in, the 1F seems good for a year - never tried going beyond it - and although it stores a nice bit of energy they're transport friendly. Catching the power going down and flashing with what's left is a good idea. I may try that for the eeprom too - although I have to have 10ms for the thing to do a page write, maybe it's short enough.