Gen3: Retained RAM or EEPROM for persistent data w/o battery back-up?

[conspiracyx]

I am laying out a door/access controller around Gen 3 hardware that obtains a list of valid key IDs from the network and stores them in memory. As a design constraint, I assume that both network and power are unreliable (including absence of battery backup). If either the network is unavailable or the device had to reboot due to power loss (or both), the device should retain and use the “last known good ID list” to manage access until it can reach the network to verify the list.

The data retention without power would mean using EEPROM, however I couldn’t deduce whether I should:

1. Use EEPROM as primary storage (all ID list CRUD operations are put() / get() to EEPROM) or
2. Fetch data out of EEPROM into some RAM var/struct at reboot, saving on EEPROM/flash wear on read operations, but perform the much less frequent writes to both

Alternatively if I wanted to utilize Retained RAM and could add a battery back-up, can I do better? Maybe somehow detect the switch to Vbatt, dump the ID list to EEPROM and brace for the battery to deplete until VUSB returns?

I read through this forum for an answer as well as @rickkas7’s Retained Memory Tips (which does not mention Gen 3 explicitly), but didn’t find a direct example for my situation. I have noted from the forums there are some edge case concerns with Retained RAM on Gen 3.

PS: To stave off downtime as much as possible, I am trying to design the hardware around an Argon on an ethernet shield with the POE module, with UPS back-up at the POE power source.

[RWB]

You now have access to the 1MB of storage via LittleFS on the Gen3 devices now.

This memory survives power loss.

[rickkas7]

There is no retained memory backup power on the Argon and Boron, like the VBAT on the Photon where you can connect a coin cell battery.

As RWB mentioned, Argon and Boron can use the LittleFS POSIX file system on 2.0.0-rc.1 and later on the Argon and Boron. It’s 2 MB and most of it is available for user use.

On Gen 3 devices, EEPROM emulation is actually a file on LittleFS flash file system. It’s hard to determine wear because it depends on how full the flash file system is. If it’s mostly empty, as it is now, data rotates through nearly 4000 sectors so the wear on any given sector is small.

There is no flash wear on read operations, only write. But you still may want to read the EEPROM into RAM because it’s more efficient to do so.

If you need both very frequent writes (many times per second) and non-volatile storage, I prefer to use FRAM. The MB85RC256V work well and connects by I2C.

[conspiracyx]

Well, shoot that’s what I get for not reading documentation closely. Thanks for the input gentlemen!

My writes are not in the millisecond range (that would change project scope dramatically), so I think my scheme #2 will do and if I need more I will re-write for LittleFS or external storage.