Zephyr NVS Factory Reset: Distinguish Logical Deletion from Data Erasure

Deleting an NVS ID removes its current logical value; it does not guarantee that every previous payload byte has been erased. A factory-reset claim must say whether it means resetting application behavior, clearing a particular storage region, or meeting a separately defined sanitization requirement. Those outcomes require different evidence.

This article examines direct Zephyr v4.2.0 NVS use. It provides a reset-assurance matrix and a disposable-image test plan. It does not certify secure erasure, prescribe a credential-destruction process, or authorize erasing a production device. A settings backend can add its own namespace and reset semantics.

1. Identify the operation behind “reset”

The versioned NVS API defines a zero-length write as removal of an entry, equivalent to deletion. A subsequent ordinary read of that deleted entry returns an error. This is an API-level statement about the current value, not proof that its former payload has disappeared from the medium.

In the v4.2.0 implementation, nvs_delete() calls the zero-length write path. A deletion entry can supersede an older record without overwriting that record’s payload. Reclaim may later remove old bytes, and a write can itself trigger reclaim; therefore neither immediate retention nor immediate erasure is guaranteed.

Proposed reset claim	Evidence needed	Insufficient evidence
The application no longer uses the old setting.	Current lookup and application behavior after restart.	A successful API return alone.
The configured NVS region was cleared.	Completed clear operation, verified target coverage, driver behavior and post-clear checks.	Deleting each known ID.
Every copy of sensitive data is unrecoverable.	A separately reviewed threat model and media-specific sanitization process covering all copies.	NVS deletion, a blank logical read, or this article.

2. Inventory the actual reset scope

List the records the application should forget and those it must preserve. Unit calibration, manufacturing identity, ownership state, network configuration, and optional preferences can have different owners and retention requirements. Do not erase a shared region merely because one component calls its operation “factory reset.”

Map the NVS instance to the exact flash device, region offset, sector size, and sector count. Include other locations that can hold copies: a second settings store, diagnostic records, staging files, external backups, and RAM caches that can rewrite values after reset. The inventory determines what a reset promise can cover.

Keep the evidence non-sensitive. Use synthetic markers in qualification images instead of real credentials or customer data. If production evidence must be retained, follow its approved handling policy; diagnostic convenience does not justify exporting secrets.

3. Understand the stronger clear operation and its limits

In v4.2.0, nvs_clear() processes the configured sectors sequentially, returns immediately on failure, and marks the instance uninitialized after successful completion. Its sector helper calls flash_flatten() and checks the readable erase value. Review these paths in the pinned NVS source rather than assuming the operation is one atomic event.

The flash API contract explains that flattening uses a device’s erase callback when applicable; when the device neither requires explicit erasure nor supplies an erase callback, it can fill the region with the device’s erase value. The API name alone therefore does not establish a physical flash-erase mechanism for every supported storage technology.

For the chosen device, confirm the actual driver, erase behavior, region coverage, and error reporting. A successful software-level check describes the accessible address range. It is not evidence about inaccessible remapped areas, another partition, an external copy, or resistance to laboratory recovery.

4. Make interrupted reset a first-class state

Quiesce application writers before an authorized whole-region clear. Otherwise a service can repopulate values from its cache or compete with the reset procedure. This is an application coordination requirement; do not assume that calling a clear API supplies a product-wide transaction.

Define what the product does when power fails or the driver reports an error partway through clearing. It must not acknowledge the stronger completed-clear claim merely because reset was requested. Record enough independent, approved state to distinguish an incomplete reset, or use a recovery workflow that treats the state as unresolved until the required checks finish.

Keep that recovery state outside any region whose erasure would destroy the only evidence of completion status, or justify another robust design. Do not invent an all-purpose flag scheme: the flag’s own interruption behavior, ownership, and endurance require qualification.

5. Run three observation views on disposable images

Prepare an authorized emulator image or sacrificial region containing only synthetic fixtures. Preserve the starting image and expected markers before each branch. No target erasure or NVS execution was performed for this article.

1. Logical deletion branch: write a distinctive payload, delete its ID, then inspect ordinary lookup and application behavior after restart.
2. Historical/raw branch: before further churn, inspect available history and a read-only acquisition of the configured region for the synthetic marker. Absence from history does not prove erasure; presence demonstrates residual bytes under that fixture.
3. Churn branch: repeat with enough unrelated activity to exercise reclaim. Observe that residual-data behavior can change without changing the logical deletion contract.
4. Completed-clear branch: verify exact target coverage, completion status, readable region state before reinitialization, and subsequent application behavior.
5. Interrupted-clear branch: interrupt at different sector boundaries and inject driver failures in a test harness. Check that partial progress never produces a completed-clear acknowledgement.

Use separate copies for raw acquisition and later remount when necessary. Reinitialization can change the store, so a post-mount image is not automatically evidence of its pre-mount state. Record the order of every operation.

History selection is relative to retained entries under the history-read API. Do not assume a fixed ordinal always retrieves the old value, and never use historical visibility as a promised recovery service after reset. It is one diagnostic observation in this fixture.

Hypothetical product wording

A controller offers “reset preferences.” Its implementation deletes preference IDs while preserving calibration. The truthful acceptance test is that old preferences no longer influence operation after restart. It cannot advertise “all device data erased,” even if ordinary reads return no preference values.

If a separate approved maintenance operation clears the entire NVS region, its evidence must include coverage, completion, interrupted-reset behavior, and the exact device/driver mechanism. Release the reset feature with the narrow claim it actually proves. Stronger sanitization language requires a stronger, separately qualified process.