We should also take into account that NVRAMs are typically erased on a page basis and that a page is of a huge size relative to the log frames. The page size varies between MCU vendors and families, but typically it's 1024 or 4096 bytes.

This leads to the question of choosing the rotation strategy (or rather granularity): on a per-page or per-frame basis.

How I image log rotation on a per-page basis:

• When reached the end of the last NVRAM page (or rather when we realize that the current slice can't fit w/o wrapping),
  • Erase the very first page of the storage
  • Put a magic number there to identify that the storage is alive
  • Set "write" & "read" heads there right after the magic number
• (edge-case) If a user has provided us with only a single page, so per-page granularity will lead to an immediate loss of previous log frames when wrapping occurs. This is sad, but still better than not wrapping because the device will still be able to function and log properly
• After a first wrap, we'll have a bubble of "free" space moving through pages with data
  • If we realize that the current data slice can't fit into this bubble, then erase the next NVRAM page and then fill the bubble, and put the rest of the slice at the beginning of the next page.

Per-page basis has the advantage that it's straightforward to implement and also won't require an auxiliary SRAM buffer to salvage log frames from the page that's being erased.

Per-frame log rotation seems to me as more complicated and full of edge cases, as well as more SRAM-consuming.

I would definitely vote for a per-page basis no matter what, even though i know i wrote n frames i did not mean it to be on a per-frame basis.

I think your suggestion here is spot on with how i imagined it to work 👍