EEPROM, FRAM and MRAM Sanitization: Write Completion Matters

Short answer

Small nonvolatile memories need their own data-disposition record. Wiping the main drive does not establish removal of target data stored in a separate EEPROM, F-RAM or MRAM component. Identify the actual component and address range, qualify its write and protection behavior, then collect completion and read-back evidence appropriate to that part.

Do not transplant a flash erase recipe or a familiar busy-polling loop into another technology. An acknowledged bus transaction, an idle status bit and a matched read-back are different observations. None alone proves that every required location on the board was processed.

Who this is for

This guide is for engineers reviewing owner-authorized embedded-board reuse or decommissioning. It uses three explicitly dated examples:

• Microchip 24AA256/24LC256/24FC256, DS21203R, the 1998–2011 revision R document.
• FM25V10 PDIP, document 002-15759 Rev. **, revised August 6, 2016.
• Everspin MR20H40/MR25H40, Revision 12.6, August 2020.

These examples are not asserted to be the newest revisions or universal behavior for every EEPROM, FRAM or MRAM. Confirm the exact suffix, package, board implementation and applicable document before an operation. No target hardware or programmer configuration is assumed here.

When to use this

Use the review when a disposal record lists only the main drive or the largest flash chip. Ask the platform owner whether smaller components hold target data such as configuration, provisioning material or state that survives power removal. Do not presume that every example category exists on every board; obtain the actual storage map.

Decide which data must be removed and whether the board must remain usable. Required calibration or identity data may need a controlled retention decision. Any authorized engineering backup becomes another copy to track, protect and eventually dispose of.

When not to use this

Do not use a generic “erase all” button on an unidentified component. Stop if address width, range, supply voltage, protection state or board isolation is unresolved. A pin-compatible package does not establish identical data-removal semantics.

Do not disable protection or write new provisioning values simply to investigate a production asset. If required data cannot be addressed by an approved procedure, hold the asset and obtain an approved alternative disposition. A failed read or unavailable interface is an unresolved observation, not proof of an empty component.

Workflow

1. Add each persistent component to the target-data map

Record board identity, component marking and reported identity where supported, package, capacity, accessible address range and host access path. Tie each range to its role in the platform and its disposition. Treat external backups and other components as separate rows rather than hiding them under one board-level “PASS.”

Record the software build and the qualified electrical setup used to access the part. Establish that the programmer reaches the intended device rather than another component sharing the bus. Prevent competing firmware activity from changing data while the qualified operation runs.

For each required area, state the approved method and expected post-operation content. A chosen replacement pattern is a logical acceptance criterion, not a technology-independent claim about microscopic recoverability.

2. Qualify EEPROM page boundaries and completion

For the 24XX256 revision used here, page writes are confined to a 64-byte physical page. Crossing that boundary wraps data within the current page rather than continuing into the next page. A host must split the work at the device's boundaries; a large transmitted byte count does not establish coverage of the same-sized address range.

The device uses an internal write cycle after the Stop condition. ACK polling can identify when that cycle has ended. However, with WP held high, a write can be acknowledged without a write cycle or data change. Therefore, a transaction ACK or immediate readiness is insufficient evidence that the intended data was replaced.

The practical review is to check the range plan, boundary splitting, protection state, completion handling and independent read-back together. A skipped page, wrapped write or protected region needs an explicit failure or exception result, not an assumed success based on the number of bytes sent.

3. Qualify the F-RAM behavior rather than inventing flash delays

For the FM25V10 PDIP example, sequential writes occur at bus speed without an EEPROM-style page buffer. Reaching the top address rolls the counter back to the beginning. A burst encountering a protected block stops advancing and ignores subsequent data bytes.

Write-enable and block-protection state therefore matter even without a long internal write delay. A generic delay added after a burst cannot resolve a protected range or an address-rollover error. Keep the planned range and actual coverage evidence explicit.

In this example, the WP pin protects status-register writes under the relevant configuration; it must not be treated as a universal direct memory-array lock. Evaluate the full protection configuration rather than inferring the result from one pin name. After power interruption, do not promote a partly transmitted stream into a completed array operation.

4. Qualify MRAM status interpretation

The MR2xH40 example supports random and sequential writes without write delays. Its status register does not update a write-in-progress bit to indicate an internal write delay. A polling loop waiting for such a transition can therefore be the wrong completion test.

The sequential address counter also rolls over at the top of memory. Review write-enable, protected ranges, selected addresses and transaction termination for the exact device. “No delay” says nothing about whether the host reached every required address before a disconnect or power event.

For a qualified procedure, retain the transmitted range and result and compare the intended post-operation content through the supported read path. Do not infer hardware sanitization certification from the technology name or a fast transaction.

5. Make interruptions and protection failures visible

Before execution, freeze the approved target, method, expected range, protection handling and irreversible boundary. Use stable power and retain actual transaction results and error records.

If power or communication is lost, record what is known and what remains unresolved. Use model-specific recovery semantics. Do not assume that every technology offers the same atomicity, resume behavior or busy indication, and do not blindly retry changes to configuration or protected storage.

After an approved retry, preserve the earlier exception in the record. A final successful read does not explain a missing region unless its scope and expected content were actually checked.

6. Verify the result and review board-level completeness

Check the required accessible range against the declared expected content. Record excluded addresses, read errors, protection restrictions and any areas the tool does not expose. Verify that addressing did not wrap or alias one region over another; repeated identical data from the wrong address is not useful coverage evidence.

Then compare the result with the original board map. A successful small-component operation is one result within that map, not evidence about the main drive, a second chip or a recovery copy. Escalate required but unresolved locations under the release policy.

NIST SP 800-88 Rev. 2 distinguishes inspecting a technique's outcome from deciding whether it adequately sanitized the target data. Keep those two decisions visible when the storage consists of several components with different interfaces.

Verification checklist

• Every component containing target data has an identity, range and disposition.
• The exact model/revision and qualified access setup are recorded.
• Page limits, rollover and protection behavior match the actual part.
• Completion checks use the device's semantics rather than an assumed busy loop.
• Read-back states the checked range, expected content and observation limits.
• Interruptions and inaccessible regions remain explicit until resolved.

Resale and evidence checklist

Retain the asset map, approved method, software and document revisions, actual range results, errors, exceptions and reviewer decision. A record should name the component processed and the scope covered. “Main drive wiped” must not stand in for an unresolved small-memory disposition.

If the board is reprovisioned afterward, distinguish newly authorized values from data retained from the previous owner. Keep any necessary recovery copy under a documented lifecycle rather than forgetting it after the board is released.

What not to publish

Keep private dumps, provisioning values, customer identifiers and confidential calibration material inside the authorized evidence system. Do not publish invented device observations, recovery probabilities or technology-wide sanitization guarantees. This workflow establishes no feature or certification of forthcoming CliDeck software.

Common mistakes

Counting ACKs as replaced data. Protection can change the meaning of a successful bus exchange.

Using one loop for every memory technology. EEPROM timing and the selected MRAM's status semantics differ.

Ignoring address rollover. A long stream can revisit earlier addresses instead of extending coverage.

Treating protection as deletion. Preventing a write or read does not remove the stored value.

Forgetting the smaller chip. The board-level target-data map determines what must be addressed.

CliDeck workflow fit

A runbook can require separate component rows, model-scoped checks and a documented exception decision. Attach actual observations when the approved workflow supports the record. This is a process recommendation, not a claim that CliDeck currently programs EEPROM, F-RAM or MRAM devices.

FAQ

Does power-off remove data from these components?

They are nonvolatile memories. Power removal alone is not a data-removal procedure; evaluate the actual component and target-data scope.

Is a universal erase opcode available?

Do not assume one across these technologies. Qualify the exact part's supported operations and completion behavior before approving a procedure.

Does full logical read-back prove microscopic irreversibility?

No. It is evidence about the selected interface and range. The accepted method and its assurance must support the broader confidentiality claim separately.

Related guides

Use the proposed sanitization coverage model, compare SPI NOR security-register scope, and review eMMC's separate storage areas.

Verification note: documentation review, no component operation

The dated device examples were reviewed against primary datasheets. No component was read, overwritten, unlocked or physically tested for this article. The checklists describe evidence a future qualified operation must collect.