The order says EEPROM content. The datasheet says the PIC32MX210F016B has no EEPROM. Both statements are true, and the gap between them is where a surprising share of recovery confusion lives. This article is about what customers are actually asking for when they ask for the EEPROM of this part, and where that data physically resides.
The Emulation Layer
Microchip’s 32-bit family carries no separate data-EEPROM array on the 1XX and 2XX members. Products that need persistent calibration, counters or user settings implement EEPROM emulation: a region of program flash is carved out and managed by a software layer that treats it as a key-value store. Records are appended into erased pages; when a page fills, valid records are compacted into a fresh page and the old one is erased. From the application’s view it behaves like EEPROM — byte-ish granularity, wear management, persistence. From the silicon’s view it is ordinary flash at ordinary addresses inside the 16 KB array from 0x1D000000 to 0x1D003FFF.
So the answer to “read the EEPROM” is: read the program flash, and the emulated store arrives with it — as long as the reader knows what the emulated region looks like. Emulation records carry headers, sequence numbers, CRCs and stale versions of the same record. A raw HEX handed over without annotation leaves the customer staring at six generations of the same setting value. The firmware extraction report maps the emulated region so the current record set can be identified.
What The Part Is For
The 210F016B is the smallest member of the 2XX family, which means it is the smallest part in this generation with a USB controller. Sixteen kilobytes of program flash, 4 KB of SRAM, 28 pins, and a full-speed USB 2.0 device/host/OTG peripheral — enough for HID-class products and little else, which is exactly the market it holds. The boot flash is the family-standard 3 KB at 0x1FC00000, holding startup code and the DEVCFG words, and on USB products it frequently holds a bootloader, since a loader that size fits the bank without touching the application array. The 230F064B page walks through the boot-bank-as-loader case at a larger density.
USB Products And Their Data
An HID product on this part stores two kinds of state: the fixed descriptors that announce its identity, and the emulated-EEPROM records for calibration and settings. The descriptors live in flash, usually near the top of the array; losing them means the recovered device enumerates as nothing. They are small, structural, and easy to overlook in a raw dump — another reason the report separates regions instead of shipping one undifferentiated HEX. The 210F016C page takes the descriptor layer up as its main subject.
What Breaks Without The Data
A rebuilt USB product without its emulated settings enumerates as itself and behaves like a stranger: calibration gone, pairing gone, user state gone. The failure mode is quiet — the device works, the customer says, but not like it used to. That gap between functional and faithful is why the report marks the emulated district instead of letting it ride inside an undifferentiated HEX. Emulation records align to the 1 KB erase pages, carry sequence numbers and checksums, and accumulate superseded generations until compaction; identifying the current set is a small, mechanical task once the region is labeled. Skipping the label is how support tickets are born months later. The same labeling discipline applies to the descriptor tables at the top of the array, which the 210F016C page treats in depth.
Capture Mechanics And Protection
The read itself is unremarkable: two independent captures of both partitions, compared word for word, with the device ID read back to confirm the die. Page geometry is 256-word erases and 32-word program rows; a page erase is 1 KB, which matters to anyone rebuilding the emulated store, because emulation pages align to the erase boundary and the report preserves that alignment.
Code protect sits in DEVCFG0 bit 28, active low. A programmed zero arms it and the flash controller blocks external reads of both partitions; Microchip’s specification gives the chip erase command as the only exit, and the erase destroys the contents. Write-protect fields guard pages during execution but leave external reads untouched. Reading the configuration words before quoting is what distinguishes a schedulable job from a difficult conversation — the copy protection page frames the assessment.
The Honest Summary
There is no EEPROM to read, and the customer’s real need is never an EEPROM — it is the settings, the calibration, the device identity. All of that is in the flash, in the emulated region and the descriptor tables, recoverable with the standard two-partition read when the part is unprotected. The trick is not the capture; it is the labeling. A report that says where the emulated store begins, which records are current, and where the descriptors sit turns 16 KB of words into the product’s persistent memory — which is what the purchase order meant all along.
The full family index, with page geometry and package for every part, sits on the PIC32MX extraction overview.