Data Logging and Parameter Storage in SPI NOR: Wear Leveling, File Systems, and Retention

Between "store a few parameters" and "log continuously" sits most of the Flash design space — and the same SPI NOR chip serves both, provided the software treats erase cycles as the scarce resource they are.

First, do the endurance math honestly

A typical Puya（普冉半导体） or Boya（博雅科技） NOR part specs 100K program/erase cycles per sector. Sounds infinite — until the arithmetic: a data logger writing 256 bytes per minute to a single 4 KB sector fills it in ~2.7 hours; erase-after-fill means 100K erases ≈ 30 years. Fine. But a device writing once per second burns through the same sector in 6 months. The design variable is not the chip — it is the write distribution.

Three storage architectures, by write pattern

• Append-only ring (continuous logging): treat the whole chip as a circular buffer of records. Writes march through sectors; an erasure happens only when the write head wraps. With a 16 Mbit part and 1 record/second at 64 bytes, the erase rate per sector drops into decades. This is the default for loggers and should be the default in your head.
• Log-structured file system (littlefs): when you need file semantics, directories, or host interop, littlefs is built for Flash: power-loss resilient, wear-aware, bounded worst case. Its overhead is real (metadata writes), so budget endurance accordingly — but it removes an entire class of "corrupted after power cut" field failures.
• Parameter records (rare, small writes): the append-only record pattern from bootloader design applies: newest CRC'd record wins, old records die of old age instead of erase cycles. A parameter set rewritten once per hour lives effectively forever on any modern NOR.

Power loss is a when, not an if

Every storage path must survive power cut at arbitrary instruction boundaries. SPI NOR gives you the primitives; the software must use them:

• Page program is atomic per page (256 bytes typically) — never span a record across pages without a CRC tail.
• Erase is the vulnerable operation. Data being erased is data being lost — so never erase the only copy of anything. Ring buffers and littlefs both obey this; hand-rolled schemes usually violate it first.
• CRC every record. The read path must treat garbage as garbage, not as data with a lucky header.

Part selection details that pay off later

• 4 KB sectors (standard on P25Q and BY25FQ families) are the granularity of wear — uniform sectors make ring-buffer math clean; mixed sector sizes complicate it.
• 1.1 V SN-class Puya parts let battery loggers run the storage rail at cell voltage — one less regulator, one less IQ line in the budget.
• Boya's on-chip ECC protects log data integrity in noisy environments (VFD cabinets, motor drives) where uncorrected bit flips would otherwise corrupt history.
• Quad-SPI for read-out: a service tool dumping 2 MB of logs over QSPI finishes in seconds instead of a minute — field-service ergonomics are a feature.

The test that separates designs from demos

Endurance and power-cut testing: script 10K+ erase/write cycles across the real access pattern (not a synthetic single-sector hammer), with power chopped at randomized offsets during program and erase, verifying full data integrity after every cycle. A design that passes this — ring buffer or littlefs, Puya or Boya silicon — is a logging architecture you can ship and forget. One that fails will fail in the field at the worst legal moment, because loggers exist precisely to record those moments.