Suffix logic that works on one family misleads on the next. On the PIC32MZ EC line, letters G, H and M select peripheral feature sets. On the EF line — this part included — the letters F, H, M and K mark silicon revisions of a single, uniform feature set: every EF die carries the floating point unit, the dual CAN controllers and the crypto engine. Treat an EF letter as a feature indicator and you will predict peripherals the die either always has or never lacks. For hex-dump work the trap is mild but real: images are compared across sibling parts, and reviewers who expect differences find none — because none exist.
One Feature Set, Four Steppings
Every PIC32MZ1024EFH064 runs the microAptiv UC core at up to 252 MHz, around 415 DMIPS, with equal-sized 32 KB instruction and data caches and a seven-stage FPU covering single and double precision. The 1 MB program array spans 0x1D000000 to 0x1D0FFFFF, erased in 16 KB pages and row-programmed in 2 KB units, with 256 KB of SRAM behind it and two 80 KB boot panels carrying startup code, the DEVCFG registers, a dedicated code-protection word and the alternate mirror set. Flash erases differently from the EC generation’s neighbors only in the same geometry all MZ parts share; what distinguishes EF in practice is AEC-Q100 Grade 1 qualification on the automotive-temperature builds and active production status while EC siblings go NRND. The family overview keeps EC and EF naming rules side by side.
Reading The Image
Capture on this part follows the six-region pattern: program flash, two boot panels, two configuration tails, plus the boot-sequence word that names the active panel. Verification adds an EF-specific wrinkle — the configuration words are ECC-protected and written by quad-word programming, so a dump must preserve not only their values but their checksum context; a config word read with a corrupted check context is silently rewritten by the hardware against the alternate set at next boot, which is exactly the kind of inconsistency a verification pass exists to catch. The hex reading workflow documents the quad-word handling.
What The FPU Changes In The Dump
Floating-point-capable cores change compiler behavior, and compiler behavior is visible in hex. Where an EC image calls library routines for every floating operation, an EF build emits native FPU instructions inline — denser arithmetic, different register-allocation patterns, and a distinctive instruction mix that reviewers use to confirm the image belongs to this generation. MicroMIPS encoding still appears for size-critical sections, so the disassembler runs in mixed mode. None of this affects the capture; all of it affects the functional review that decides whether the image is trustworthy.
Diffing Across Steppings
The revision-letter system gives recovery work an unusual tool: images from F, H, M and K stepping parts of the same flash size should be byte-identical when built from the same sources, and near-identical when field updates separate them. When a client supplies more than one sample, the diff between their images dates builds, exposes post-release patches, and occasionally reveals that the same product shipped two firmware generations. The findings feed the report as provenance: which image is newest, what changed between them, and which one the client’s fleet actually runs. It is cheap analysis on top of a capture that had to happen anyway.
Protection, Unchanged In Spirit
One active-low code-protection word guards the array. Cleared, it closes ICSP and the 4-wire JTAG port together; release comes only through the chip-erase command that destroys the image. Write protection lives in flash-controller registers re-applied at boot. As always, destructive steps wait for ownership verification through the services desk.
The 100-pin sibling of this die, common in industrial HMI designs, is covered on the 1024EFH100 page, which adds the automotive compliance workflow.