Some protection mechanisms announce themselves with a locked probe. The PIC32MZ1024EFM100’s quieter mechanism trips people differently: its configuration words are ECC-guarded, quad-word programmed, and shadowed by an alternate set the hardware switches to when the primary copy develops an uncorrectable fault. A recovery workflow that treats those words as ordinary flash bytes can corrupt their check context, force the device into its fallback configuration, and turn a healthy controller into one that boots with wrong clock, watchdog or debug settings. Reading this part well means respecting the machinery.
The Two-Copy Configuration Scheme
At the tail of each 80 KB boot panel sit the configuration words: DEVCFG0 through DEVCFG3 plus a dedicated code-protection word, all written by quad-word programming so the ECC check bits stay consistent. Behind them stands the alternate set — a mirrored block the hardware consults when the primary copy’s ECC fails, flagged through BCFGERR and BCFGFAIL bits in the reset controller. Configuration bits are write-once per power cycle and continuously compared against stored complements; a mismatch forces a reset rather than a wrong boot. A complete capture reads both copies in both panels — four configuration contexts in total — and validates each in its ECC framing. The family overview diagrams the arrangement.
The Rest Of The Capture
Program flash spans 0x1D000000 to 0x1D0FFFFF in 16 KB erase pages, row-programmed 2 KB at a time, with 256 KB of SRAM behind it. The core is the EF-generation microAptiv UC at up to 252 MHz and about 415 DMIPS — seven-stage FPU, 32 KB caches, dual CAN, crypto engine with TRNG — and the M suffix marks a silicon revision, not a feature change. Verification walks page checksums, structure checks and a bench boot, with the configuration census reported explicitly: which copy was active, whether the alternate agrees, and what the boot-sequence word selects. The verification workflow documents the format.
Reading The Fallback State First
Before any capture, the reset controller’s status bits are checked, because they narrate the part’s history. BCFGERR set means the primary configuration copy has already faulted and the device has been running on the alternate set, which means the image a client believes it is running may have been configured differently than the source code intends. BCFGFAIL means both copies failed and the hardware fell to defaults, a state that usually explains a board behaving strangely long before anyone mentions firmware recovery. The read then captures all four configuration contexts deliberately, and the report states which copy governed the last boot. On this part, configuration provenance is part of the deliverable, not a footnote.
Why Clients Hit This Part
It is the successor pick. Designs migrating off the EC family land on EF parts like this one, and requests follow the migration wave: a replacement controller must be flashed with the original binary, or the original binary must be understood well enough to port. The read is the common first step of both. Where the port is the goal, the deliverable includes the peripheral census — every register the image touches — so the differences against the destination die are known before code changes start. The migration scenario from the EC side is told on the 2048ECM100 page.
Protection And The Destructive Path
The code-protection word remains the single gate: active-low, locking ICSP and the 4-wire JTAG port together once cleared, releasable only by a chip erase that takes the image and both config copies with it. On an ECC-scheme part the destructive path has one extra consequence — the erase also resets the configuration ECC state, so a re-flashed unit starts from a clean slate regardless of what the old copies held. Authorization and ownership evidence precede any such step, arranged through the services desk.
The 124-pin sibling of this die, and the interrupted-update corner cases its twin panels create, appear on the 1024EFM124 page.