EEPROM on the H7xx would be nice

n2wx · ‎2020-03-11

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....

n2wx · ‎2020-03-11

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.

View solution in original post

waclawek.jan · ‎2020-03-11

#STM32-Wishlist

berendi · ‎2020-03-11

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.

RMcCa · ‎2020-03-11

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.

Tesla DeLorean · ‎2020-03-11

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

n2wx · ‎2020-03-11

> 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.

n2wx · ‎2020-03-11

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 · ‎2020-03-11

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 · ‎2020-03-11

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 · ‎2020-03-11

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.