Map NOR Flash Erase Regions Separately from Program Pages

A serial NOR flash can accept a small program operation while requiring a much larger erase operation to prepare that location. A memory map that allocates records only by their data length can therefore place unrelated information inside the same erase region. Review erase ownership before implementing updates.

Record both geometries

Infineon’s S25FL064L datasheet identifies a 256-byte program buffer and several larger erase options. The selected device’s command set and restrictions determine the valid operations. These dimensions are not interchangeable, and another flash family can organize its array differently.

Create a geometry record containing capacity, address mode, program-page boundaries, supported erase units and protected regions. Attach it to the exact ordering code and driver configuration. Avoid relying on capacity alone when substituting another part.

Assign ownership at the erase level

For an illustrative device with a 4 KiB erase unit, a 100-byte calibration record and a separate configuration record can still share one erase operation if placed in the same unit. Updating one must not silently destroy the other. The small size of either record does not change that relationship.

Mark each erase region with its owner and update policy. If several records share a region, define how unchanged data are preserved and how an interrupted update is detected. Alternatively, allocate independent regions when the required isolation justifies the space.

Review the update sequence

Follow the device’s required preparation, erase, program and status-check sequence. Split programming at the permitted page boundaries and verify completion before dependent operations. Treat a busy indication, a protection failure and a data mismatch as different outcomes in the diagnostic record.

Read back both the intended new data and any neighboring data that the update must preserve. Where checksums or version fields are used, define what they cover and when a record becomes valid. A checksum alone does not explain how the previous valid state survives an interrupted erase.

Test interruption deliberately

Use a controlled development setup to interrupt updates at representative stages and verify startup recovery. Keep expendable test regions separate from irreplaceable provisioning or boot information. The expected result should be defined before running the fault test, including what the software reports when neither candidate record is valid.

Retain the erase-region map, update state diagram and recovery evidence with the firmware release. If a bootloader, partition layout or flash part changes, review these boundaries again. This prevents a locally correct page-program routine from becoming a system-level data-loss mechanism when unrelated records share its erase region.