Microchip part numbers carry a lot of cargo, and on the PIC32MZ1024ECG064 the letter G is the cargo that decides how a firmware extraction gets planned. The naming system in the EC family data sheet is explicit: G parts carry the EC feature set with no CAN controller and no hardware crypto engine. H parts add dual CAN. M parts add CAN and the AES/SHA cipher block. Nothing else separates them — same 200 MHz microAptiv core, same 1 MB of program flash, same 64-pin footprint. A board marked G really is the reduced die, and knowing that before the first probe touches the package saves a full round of wrong assumptions.
What The Core Looks Like From The Outside
The EC family runs a MIPS32 microAptiv core at 200 MHz, about 330 DMIPS, with a five-stage pipeline, a 16 KB instruction cache and a 4 KB data cache. There is no floating point unit anywhere in the family — that arrives with the later EF generation. The core does carry DSP extensions, four 64-bit accumulators and a single-cycle MAC, plus microMIPS encoding for tighter code. All of this matters after the read: a recovered image from this part disassembles as a mix of MIPS32 and microMIPS encodings, and the DSP accumulator instructions leave fingerprints that help confirm the toolchain that built the image. The family overview maps where every letter variant sits.
The G Variant In Practice
Because the G die has no CAN and no crypto engine, images built for it lean on software stacks: bit-banged or UART-framed protocols instead of CAN frames, and software AES instead of the cipher peripheral. That changes what a recovered binary contains. There is no key material hidden behind a hardware engine because there is no hardware engine; if the designer encrypted anything, the key is an ordinary constant in the flash array. For extraction clients this is usually good news — the image is self-contained, and re-hosting it onto another board is a matter of burning one file rather than recovering secrets from several places.
The 1 MB array spans 0x1D000000 to 0x1D0FFFFF, erased in 16 KB pages and row-programmed in 2 KB units. Around it sit 256 KB of SRAM and two 80 KB boot panels used for live-update swapping.
Why NRND Matters To The Job
Microchip has moved the whole EC line to not-recommended-for-new-designs status and points buyers at the EF family. That shifts the typical request pattern. Instead of recovering code to repair a production line, most G-variant jobs now feed migration projects: an old controller dies, a replacement is unavailable, and the choice is between redesigning the board or lifting the firmware and dropping it onto an EF part with the same pinout. The second option only works if the extracted image is complete and verified — including the configuration words, which on this family live as a separate code-protection word and four DEVCFG registers at the top of the boot panel, mirrored by an alternate set that the device falls back to on ECC faults.
Our chip analysis workflow covers how that verification is staged: read, checksum, cross-check against the alternate config block, then a functional bench test before anything ships.
Protection Model On This Part
One protection bit governs everything. The code-protection configuration word, programmed alongside DEVCFG0 through 3, is active-low; once cleared, ICSP and the 4-wire JTAG port lock simultaneously and the only release is a full chip erase, which destroys the image. Read-protection on this family is binary — there are no regional read fences. Write protection is different and lives in flash-controller registers rather than the configuration words, so it survives only while the firmware sets it up at boot. A locked G part therefore has exactly one obstacle, and the decision on how to cross it is a conversation about authorization, not about tooling. Requests go through the service desk with ownership evidence attached.
For contrast, the larger 2 MB sibling of this die is covered on the 2048ECG064 page, where the dual-panel live-update layout adds a stitching problem the 1 MB part shares.