PIC32MZ Firmware Extraction: EC And EF Family Map

Microchip’s PIC32MZ generation replaced the PIC32MX line with a bigger core, a different flash architecture and a protection scheme that looks similar from the outside but behaves differently in the details. This page is the family map: how the part numbers decode, what the silicon actually protects, how the flash is organized, and where each of the twenty variants we profile in depth can be found. It sits alongside the PIC32MX family overview, which covers the earlier generation the same way.

Two Families Behind One Name

The MZ line splits into two generations. The EC family runs a MIPS32 microAptiv core at 200 MHz — about 330 DMIPS — with a five-stage pipeline, a 16 KB instruction cache against a 4 KB data cache, DSP accumulators and microMIPS encoding, and no floating point unit. The EF family runs a microAptiv UC core up to 252 MHz and about 415 DMIPS, with equal 32 KB caches and a seven-stage FPU that handles single and double precision natively. Microchip has marked the entire EC line not recommended for new designs and points buyers at EF, which changes the shape of most recovery requests: fewer repairs, more migrations.

The suffix letters mean different things per family, and mixing the two systems is the most common reading error. On EC parts, the letter selects peripherals: G carries no CAN and no crypto engine, H adds the dual CAN controllers, M adds both plus the AES/SHA cipher block with its random number generator. On EF parts, the letters F, H, M and K are silicon revisions of one uniform feature set — every EF die carries the FPU, the CAN pair and the crypto engine. The digits before the letters give flash size (1024 or 2048 KB) and the trailing digits give pin count: 064, 100, 124 or 144.

Flash Geometry, Different From MX

Program flash starts at 0x1D000000 and reaches 0x1D0FFFFF on 1 MB parts and 0x1D1FFFFF on 2 MB parts. Erase granularity is coarse by MX standards: pages of 4096 words, or 16 KB, with eight rows of 512 words — 2 KB — per page for row programming. The boot region is not one bank but two independent 80 KB panels, at 0x1FC00000–0x1FC13FFF and 0x1FC20000–0x1FC33FFF, supporting live update: the device can rewrite one panel while running from the other. SRAM scales with flash density — 256 KB behind 1 MB arrays, 512 KB behind 2 MB. There is no internal EEPROM; data that survives power goes into the same 16 KB pages, which is why firmware designers store parameters the way they do.

One Protection Word, Mirrored

Code protection is a single active-low configuration word, and — unlike PIC32MX, where the CP bit lives inside DEVCFG0 — the MZ generation gives it a dedicated word of its own at the top of the boot panel, next to DEVCFG0 through DEVCFG3. Configuration words are ECC-protected and written by quad-word programming, and each primary set is shadowed by an alternate copy: if the primary develops an uncorrectable ECC fault, the hardware switches to the alternate and flags the event through BCFGERR and BCFGFAIL in the reset controller. Once the protection word is cleared, reads close over ICSP and the 4-wire JTAG port simultaneously — there is no debug-TAP side door — and the only release command is a full chip erase, which takes both panels, both config copies and the image with them. Write protection is a different mechanism entirely: PWP and BWP are flash-controller registers re-applied by boot code, effective at runtime and irrelevant against an attack on the silicon itself.

The Twenty Variants In Depth

Each page below profiles one part: what the suffix implies for the image, how the extraction and verification run, and what typically fills the array in that package. All of them link back here and to the conversion routes on the services page.

How An Engagement Runs

Intake starts with the part number and the protection state: unlocked parts read directly through ICSP; locked parts escalate only after ownership verification, arranged through the contact desk. The capture takes program flash, both boot panels and all configuration contexts, validates page checksums and ECC framing, and closes with a bench boot. Deliverables are a verified binary plus a report — region manifest, configuration provenance, peripheral census — built so the image can be re-flashed or ported without surprises. The general workflow, common across Microchip families, is described in the firmware extraction overview.