Ask for a binary copy of a PIC32MX220F032B and you will get what you asked for: a HEX covering the 32 KB program array. Ask for a copy that boots, and the scope triples. This part — 32 KB of flash, 8 KB of SRAM, 28 pins, full-speed USB — splits its non-volatile contents across three regions with three different jobs, and a copy that captures one of the three is a copy of a third of the product.
Region One: The Program Array
Program flash runs from 0x1D000000 to 0x1D007FFF and holds the application: code, constant tables, and — on parts without a separate data store — emulated EEPROM records managed by a software layer. Page erases are 256 words (1 KB) and program rows are 32 words (128 bytes), which is the geometry any reconstruction must respect when rebuilding or patching. Erased words read all ones, so the boundary between live code and padding is measurable, and on a production image it is worth measuring: rebuilds want to know how much of the array was in use.
Region Two: The Boot Bank
Three kilobytes at 0x1FC00000 through 0x1FC00BFF, in its own erase domain. It holds the C startup code that runs before the application, and — frequently on USB parts like this one — a bootloader, because a serial or HID loader fits the bank without spending application flash. A copy without the boot bank produces a part that boots into nothing, or into the previous tenant’s loader. A copy without the loader’s copy produces two variants of the same product that enumerate or update differently, which takes weeks to trace back to the missing kilobytes.
Why Geometry Matters To A Copy
The 256-word page and 32-word row are not trivia; they are the constraints a reconstruction inherits. A patched image must erase and rewrite in whole pages — 1 KB at a time — and a patch that crosses a page boundary silently rewrites the neighbor. Rows program 128 bytes at a stroke, so partial updates leave the rest of the row untouched only if the tooling knows the boundary. Rebuilding an emulated-EEPROM district adds the same constraint from the other side: records align to erase pages, and a reconstruction that forgets it produces a store that compacts itself into chaos. The geometry is printed in the programming specification, and honoring it is what separates a capture from a buildable image.
Region Three: The Configuration Words
Four DEVCFG words sit in the last page of the boot partition. They select the oscillator and PLL chain, the watchdog policy, the debug channel, and the protection state. They are the smallest region and the most common cause of “the copy matches the HEX and still will not start”: a board programmed with default configuration words clocks from a source the design never wired, or waits for a debugger that is not there. The words are also where the code-protect bit lives — DEVCFG0 bit 28, active low, armed by a programmed zero, clearable only by the chip erase that destroys the image. A copy operation reads them first, because they state what the part permits.
What The Bootloader Changes
A loader in the boot bank alters the copy’s obligations. It is the first code to run after reset, it decides what the update interface accepts, and it frequently enforces the product’s update signature checks. A copy that preserves the application but not the loader ships a part that cannot be updated the way the original was — or worse, one that accepts updates the original would have refused. Conversely, a loader captured without the application is inert: it waits for a host that speaks a protocol nobody documented. The pair is the product’s front door, and the copy takes both or takes nothing that can be trusted. The read-mcu-firmware page describes how capture and reconstruction divide this work, and why the loader’s copy is verified against the original before anything ships.
The Verification Standard
Two independent captures of all three regions, compared word for word. Device ID read back to confirm the die — this part shares footprints with the 110F016B and 120F032B, and density surprises on production boards are common enough that the 120F032B page makes identification its main subject. The result is not one file but one package: program flash, boot bank, configuration, each labeled, each aligned to its erase boundary. The reading process page describes the capture mechanics in detail.
Copying As An Engineering Act
The word copying suggests duplication; the work is closer to reconstruction. The firmware extraction overview describes how the captured package becomes a buildable image, and the contact page starts the job. What makes the difference between a HEX archive and a working copy is rarely the silicon — the 220F032B is a cooperative part with a well-documented interface — it is whether the person doing the capturing knew that the product existed in three places, not one, and brought all three back.
Geometry for the rest of the branch, including the 100-pin exception, is on the PIC32MX overview page.