Quick answer
A memory IC’s part number identifies the device, not the data currently stored inside it. Before buying legacy Flash, EEPROM or a configuration PROM, specify whether you need blank material, a customer-approved programmed image, or material whose programming state must first be established. A package marking, inventory listing or successful device-identification command is not a substitute for that agreement.
For a repair team, receiving the correct chip with the wrong contents can be as disruptive as receiving the wrong chip. For production, a vaguely described “blank” lot can leave programming responsibility and acceptance checks unresolved. The aim is to separate device identity, material condition and memory contents before placing the order.
1. Define the programming state in the quotation
The following labels are a suggested purchasing vocabulary, not an industry certification scheme:
| Requested state | What the buyer should clarify |
|---|---|
| Blank, verified | The device-specific blank-check method, checked address range, quantity checked and lot-linked results. |
| Erased, checked | The erase method and subsequent verification. An erase operation does not establish unused history. |
| Preprogrammed, approved image | The authorized file revision, programming scope, relevant settings and verification record. |
| Programming state unknown | No assumption of blankness. Agree the evaluation and acceptance route before production use. |
Keep condition separate from these labels. “Blank” does not by itself mean unused or authentic; “programmed” does not by itself mean defective. Ask for the basis of every statement, and identify who will perform any required programming or verification.
2. Do not apply one erase rule to every memory technology
EPROM: check whether the exact package is UV-erasable or OTP
STMicroelectronics’ M27C512 datasheet distinguishes UV EPROM and one-time-programmable versions. It describes a windowed ceramic package that permits UV erasure and states that delivered devices, and UV devices after erasure, have all bits at logic one. These manufacturer specifications do not establish the present contents or history of a secondary-market lot. [1]
The procurement lesson is straightforward: do not accept a generic promise to “erase any EPROM.” Confirm the exact variant and approved process. An OTP device must not be treated as electrically erasable Flash, and a previously programmed windowed EPROM still requires an agreed assessment.
The M27C512-12F1 listing is an exact ordering-code example. Its inclusion here is not a claim that the offered material has been blank-checked.
EEPROM: an interface response is not proof of a successful write
Microchip’s AT24C512C datasheet explains that an asserted WP pin protects the memory array. A write attempt can still receive acknowledgements for the address and data while no internal write cycle occurs. [2]
For purchasing, this is a reason to request the actual verification result rather than accept “the programmer communicated with the device.” The responsible engineer should define the procedure and relevant hardware conditions. Our AT24C512C-MAHM-T listing identifies a specific serial EEPROM, not its current programmed contents.
FPGA configuration PROMs: a default user code is not a whole-device blank check
Xilinx’s DS123, now hosted by AMD, describes the XCF32P Platform Flash family as reprogrammable configuration storage. It recommends verification after programming. Crucially, the USERCODE register can contain FFFFFFFFh when the device is blank or when that register was not loaded during programming. The document also describes protection settings that affect read/verify access. [3]
Therefore, an all-F USERCODE alone does not establish that the full configuration memory is blank. State the required content and settings, and agree how verification will be performed. See the XCF32PFSG48C listing for an ordering-code example—not a declaration that a particular customer bitstream is already installed.
3. Control the file before requesting preprogrammed supply
If your order requires programmed parts, “load our firmware” is not a complete specification. Provide a controlled instruction that identifies:
- The complete ordering code and applicable board or equipment revision.
- The approved file name, release revision, format and agreed digest or checksum.
- The required address range, offset and treatment of unused locations.
- Any configuration or protection settings, defined by the responsible engineer.
- The verification method, scope, required record and release authority.
A file digest can help identify the intended file, but it does not prove device authenticity or application compatibility. Likewise, matching stored data does not replace application validation. Keep those decisions distinct.
Do not send confidential firmware or production data to a supplier unless your organization has authorized the transfer and agreed on an appropriate handling method. Do not authorize copying an unknown device’s contents merely to create a replacement image.
4. Preserve unknown contents before authorizing destructive work
If programming state is unknown, pause before erasing or writing. A repair device may contain information the customer needs to preserve. Ask engineering to decide whether a permitted, non-destructive read is appropriate, whether the original data must be retained and whether the proposed work is authorized.
Do not attempt to bypass read protection. If normal verification is unavailable, record the limitation and obtain an acceptance decision rather than describing the device as verified. Unresolved programming state should remain unresolved in the quotation and inspection record.
5. Agree exactly what the inspection record will cover
A useful record ties the result to the offered material. Specify the lot reference, quantity assessed, device and adapter used, method or procedure revision, checked range, result and date. If only a sample was checked, report that scope clearly; do not imply every piece was verified.
A blank check addresses a defined memory state under a defined procedure. It does not establish all electrical characteristics, storage history, remaining endurance or authenticity. Select additional checks according to the application’s risk and your engineering or quality requirements.
For the wider documentation package, see our guide to CoC, traceability and inspection records.
Suggested RFQ wording
“Please quote the exact manufacturer ordering code below. State the material condition and whether its programming state is verified blank, erased and checked, programmed, or unknown. Do not erase, write, copy contents or set protection options without our written authorization. Any required programming or verification must follow our approved instruction and be reported with its actual scope.”
Add your quantity, delivery requirement and acceptance conditions. Use the complete RFQ checklist for the remaining procurement fields.
Frequently asked questions
Does “new” automatically mean a memory IC is blank?
Do not infer programming state from the word alone. Ask what the supplier means, what evidence supports the statement and whether the device-specific blank condition has been checked.
Does a blank check prove that a chip is genuine?
No. It addresses memory contents within its stated scope. Identity, provenance, condition and any required authenticity assessment remain separate questions.
Can every programmed legacy memory IC be erased and reused?
No. Technology, variant and protection state matter. Do not assume OTP, UV EPROM, EEPROM and Flash share one reset procedure.
Does XCF32P USERCODE FFFFFFFFh prove the PROM is blank?
No. DS123 gives more than one reason for that value. Use an appropriate device-specific check rather than one identification field.
Enquire about legacy memory components
Send ZZX Electronics your exact ordering code, quantity, required delivery and programming-state requirement. Ask us to confirm the available material and what documentation or inspection scope can be included in a written quotation. The three linked products are catalogue examples; this article does not certify their present contents, reserve stock or promise programming services.
Contact ZZX Electronics, or read our legacy memory sourcing article for the broader procurement context.
Sources and technical references
- [1] STMicroelectronics M27C512 datasheet, Rev 3, May 2007 — manufacturer-authored copy hosted by Datasheets.com; description, programming and erasure sections.
- [2] Microchip AT24C512C datasheet, DS20006161D — section 7.5, write protection; ordering information.
- [3] Xilinx Platform Flash Configuration PROM datasheet, DS123 v2.19, June 6, 2016 — programming, protection and USERCODE sections; official AMD documentation archive.
Technical sources and linked listings checked October 12, 2026. This is a procurement checklist, not a device-programming procedure or an acceptance certificate. Follow the exact device documentation and customer-approved engineering requirements. Images are AI-generated editorial illustrations, not photographs of ZZX stock, facilities or completed tests.
