Two part numbers can describe one piece of silicon. Within the PIC32MZ EC family, the letter after the family code — G, H, or M — does not select a different die revision the way older Microchip suffixes sometimes did. It selects which peripheral fuses the vendor considers enabled: G parts ship without CAN and without the crypto engine, H parts enable the dual CAN controllers, M parts enable both. The core, the caches, the flash controller and the pads are family hardware. For anyone reading firmware back off a PIC32MZ2048ECH100, that distinction matters in one specific way: the image will never contain code driving peripherals the die was fused without, and spotting that absence quickly tells the reviewer whether the read is complete.
What The Read Captures
Program flash on this part covers 0x1D000000 through 0x1D1FFFFF — 128 pages of 16 KB, row-programmed 2 KB at a time. The complete capture adds the two 80 KB boot panels at 0x1FC00000 and 0x1FC20000, each ending in a configuration block: the four DEVCFG registers plus the family’s dedicated code-protection word, with an alternate mirror standing by for ECC faults. Nothing else on the package holds executable state; 512 KB of SRAM is volatile and vanishes at reset. The family overview lays out all six regions with addresses.
Verification walks the capture in three passes: page checksums against the programmer’s record, structural sanity across vector tables and jump targets, and a boot test on a reference board. Only after all three does the image leave the lab. The verification pipeline documents the criteria.
The Core, Briefly
The EC generation runs microAptiv at 200 MHz — about 330 DMIPS — with a five-stage pipeline, 16 KB instruction cache against a small 4 KB data cache, DSP accumulators for filter-heavy code, and microMIPS encoding that compresses typical C output noticeably. No FPU exists in this generation; floating-point work compiles to library calls whose weight is visible in the image. The 100-pin package mostly changes pin budget, not behavior: more analog inputs routed to the 48-channel 10-bit converter, more remappable I/O.
The report keeps this evidence compact: two lines per panel, image identity, and the selection word’s value at capture.
Reading Around Live-Update State
Dual-panel flash means field-updated boards may run code the factory never flashed. The boot sequence word selects a panel; the other holds the previous image. A careful read captures both and reports which one the boot word currently selects, because the distinction decides what the client is actually running. Where the panels disagree, the delta is itself informative — it dates the last field update and sometimes reveals post-release fixes worth preserving in documentation. The same logic on the EF generation, with interrupted updates, is examined on the 1024EFM124 page.
The Panel Selection Note
Every delivery from a dual-panel part includes one line clients learn to care about: which panel was selected at capture, and what the other held. It sounds bureaucratic until the day it isn’t, because a fleet where some units received a field update and some did not diverges quietly, and the panel note is the first place the divergence becomes visible in a recovery project. Where the two panels hold different images, both are delivered, dated by their build metadata, with the boot word’s current selection stated. The client’s maintenance records usually explain the split; when they don’t, the images themselves become the record.
Protection And Process
Code protection is the same single active-low word as the rest of the family: cleared, it closes ICSP and JTAG together, and only a chip erase — destructive to both panels — releases it. Write protection is boot-software in flash-controller registers, not a fuse. Engagements run under documented ownership with the destructive decision made consciously, through the services desk. The 64-pin CAN node variant of this die is treated on the 2048ECH064 page.