Completeness is a list, not a feeling. For the PIC32MX250F128D — the 44-pin, full-feature member of the flagship small-package family — the list has five items, and jobs that skip items two or four produce images that boot, run, and fail in ways nobody can trace for months. Here is the checklist as it is actually executed.
One: Program Flash
128 KB from 0x1D000000 to 0x1D01FFFF: application code, constant tables, and the emulated-EEPROM district where persistent settings live as appended records — the part has no dedicated EEPROM array, so settings ride in flash under a software compaction layer. Captured in full, including the erased tail, whose all-ones words mark where the live code ends. Page erases are 256 words, program rows 32; the geometry matters to anyone rebuilding or patching, so the report preserves alignment.
Why The 44-Pin Flagship Exists
Forty-four pins on this family is the package where the peripheral set stops compromising. Both UARTs, both SPI/I2S ports and both I2C buses route simultaneously — the smaller packages force them to share — and the 13-input converter, the parallel master port and the USB controller all reach the outside world at once. Products here are multi-bus by nature: a device that talks USB to a host, I2S to a codec, and I2C to a power monitor is unremarkable in this package. The pin-select matrix arranges the traffic, and its configuration — recovered with the image — is the authoritative pinout. Design documents drift; the configuration words in the flash do not.
Two: Boot Flash
Three kilobytes at 0x1FC00000 through 0x1FC00BFF, its own erase domain, holding the C startup path and — on a large fraction of products — a bootloader. The boot bank survives application updates precisely because updates leave it alone; copies that skip it leave the same gap. On this part the 44 pins tend to carry products with USB and I2S audio, and boot-loadable firmware is the norm rather than the exception. The 220F032B page walks the three-region structure; the principle is identical at 128 KB.
Three: Configuration Words
Four DEVCFG words in the boot partition’s last page. They select the oscillator and PLL chain behind the 50 MHz, 83 DMIPS core, set the watchdog policy, steer the debug channel, and hold the code-protect bit — DEVCFG0 bit 28, active low. A programmed zero there blocks external reads of both partitions, and the only documented exit is the chip erase that destroys the image. Reading these four words first is what turns an unknown part into a schedulable job; skipping them is how reconstructed images boot at the wrong clock or not at all.
Four: The Device ID
Not part of the image, part of the evidence. The ID read back from the programming interface pins the die — density, revision, family. It cross-checks the marking, catches stock substitutions, and anchors the configuration words to the silicon that actually shipped. On a part whose 44-pin footprints are shared across densities, it is the difference between a verified read and an assumption with a file extension.
The Two Regions Most Captures Forget
Item two and item three fail in characteristic ways. Boot banks vanish from copies because tools default to the program array and the operator confirms without checking scope; three kilobytes of loader disappears and the rebuilt part boots into a blank domain. Configuration words vanish for the same default-shaped reason — some tools read them separately, some embed them, and an operator mid-checklist may not notice which happened. Both omissions produce images that pass a size check and fail a board. The checklist exists because defaults are adversarial: each item is confirmed by address, by length and by content, not by the tool’s summary line. Minutes per item, hours saved later. The chip extraction analysis service applies the same checklist at board level when several memories share the product.
Five: Verification
Two independent captures of each region, compared word for word. Not a checksum on one capture — two captures, taken separately, agreeing bit for bit. The reading process page describes the mechanics; the discipline costs minutes and converts a plausible image into a defensible one. The chip extraction analysis service extends the same standard to the board around the part when the job is product-level.
What The Five Items Buy
An image that is complete by this definition can be rebuilt from, patched, ported, or archived with confidence, because nothing that the product needed at power-on is missing: the code runs, the loader loads, the clocks are right, the identity is certain, and the capture is proven. Images that omit the boot bank boot into nothing; images that omit the configuration words boot wrong; images without verification are merely hopeful. The firmware extraction overview describes how the five items are packaged, and the contact page starts the job. The 250F128D is a cooperative subject — the checklist is short, and it is the whole difference between a file and a product.
Geometry for the rest of the branch, including the 100-pin exception, is on the PIC32MX overview page.