Datasheets advertise peripherals; boards wire them up. On the PIC32MZ2048ECG100, the peripheral that dominates most designs is the 48-channel, 10-bit converter sampling at up to 500 ksps through a single sample-and-hold. A 100-pin package carrying this die is usually the heart of a data logger, a test instrument or an industrial controller, and its firmware — the thing a client needs recovered — is built around scan sequences, trigger tables and calibration constants rather than around communication stacks. Knowing that changes where a reviewer looks first in a read-back image.
The Die Under The Package
The EC letter marks Microchip’s embedded-connectivity generation: a microAptiv core at 200 MHz and about 330 DMIPS, five-stage pipeline, 16 KB instruction cache, 4 KB data cache, DSP accumulators, microMIPS encoding, and no floating point unit. The G feature set omits CAN and the crypto engine; the 2 MB program flash spans 0x1D000000 to 0x1D1FFFFF, backed by 512 KB of SRAM and two 80 KB boot panels. Flash erases in 16 KB pages and programs in 2 KB rows, a granularity that matters when distinguishing firmware regions from the parameter blocks these instruments almost always store in the highest pages of the array.
Reading An Acquisition-Focused Image
Images of this breed have a recognizable anatomy. Near the vector table sit the scan-sequence engines: lists of channel numbers, trigger sources and sample times, written at boot into converter registers. Deeper in the array, calibration constants — gain and offset pairs per channel — usually live in a reserved page with its own version stamp. Application code wraps both. A verification pass therefore checks three things beyond bare checksums: that scan tables parse as plausible channel lists, that calibration pages carry sane numeric ranges rather than erased bytes, and that the code region contains no references into unmapped space. The firmware reading overview describes the full checklist.
None of this changes the fundamental capture: program flash, both boot panels, and the configuration blocks at their tails, which on this generation include a dedicated code-protection word plus an alternate mirror for ECC-fault fallback. The family overview collects the memory map details in one place.
Trigger Architecture In The Image
Sampling this fast on a 10-bit converter is orchestrated by triggers, and the firmware’s trigger setup is one of the more legible structures in the image: lists pairing channels with sources, interval tables for periodic scans, and interrupt handlers sized to move results before the next conversion. The review extracts these lists during verification because they answer the client’s most common question, which inputs feed which logic, more directly than the code that consumes the results. On multi-board systems, that mapping is often the documentation nobody wrote.
Why Clients Come To This Part
Two scenarios dominate. In the first, an instrument maker has lost its source and needs a working image to flash onto replacement controllers — the deliverable is a verified binary plus checksum evidence. In the second, the calibration content itself is the prize: years of field-tuned channel corrections that no documentation recorded. Both start from the same complete read, and both depend on the parameter pages surviving the capture; a read that treats the top of the array as padding destroys exactly the data the client cares about most.
Protection Posture
Code protection on this family is binary and severe: one active-low configuration word, and once it is cleared the device rejects reads over ICSP and JTAG alike, with a full chip erase as the only release — an operation that takes the image and the calibration pages with it. Write protection lives in flash-controller SFRs and is only as permanent as the boot code that re-applies it. Engagements proceed under documented ownership and through the contact desk; the extraction services overview outlines what evidence is required.
For the 144-pin relative of this die, whose external bus and quad-SPI interfaces change what belongs inside the image, see the 2048ECG144 page.