Every flash array has an edge, and on the PIC32MZ1024ECH064 the edge falls at 0x1D0FFFFF. One megabyte of program flash starts at 0x1D000000, and the read that stops a few kilobytes short — because the final pages look empty, or because the tool’s address window was set for a smaller part — produces an image that boots until the firmware jumps into the hole. Recovery work on this part starts with the boundary, not with the probe.
The Array And Its Granularity
Program flash on the MZ generation erases in 16 KB pages and programs in 2 KB rows, eight rows to a page. That granularity shapes the tail of the image. Compilers pad the last code page, a bootloader occupies whole pages for alignment, and parameters sometimes sit in the final page precisely because nothing else claims it. A 1 MB image read back page by page is 64 pages; the difference between 62 and 64 is often the difference between a bootable binary and a brick. Verification therefore walks the full range and flags every page whose checksum disagrees with what the programmer expected.
What The H Letter Brings
The EC family suffix system is unambiguous: H parts add the dual CAN 2.0B controllers that G parts omit, still without the crypto engine that M and the EF generation carry. Inside a recovered image, that difference is visible. CAN initialization code, message object tables and interrupt vectors for the two controllers occupy flash that a G-variant image spends elsewhere. For a client rebuilding a discontinued board, those tables are frequently the valuable part — they encode arbitration IDs, DLCs and payload layouts that document nothing recorded. Our firmware reading pipeline treats them as first-class output, not as undifferentiated hex.
The core driving it is the same 200 MHz microAptiv as the rest of the EC line: five-stage pipeline, 16 KB instruction cache against a 4 KB data cache, DSP accumulators, microMIPS encoding, no FPU. Around it, 256 KB of SRAM and two 80 KB boot panels.
Boot Panels And The Config Tail
Both boot panels at 0x1FC00000 and 0x1FC20000 hold startup code, and each ends in a configuration block: DEVCFG0 through DEVCFG3 plus a dedicated code-protection word, with an alternate mirror the hardware switches to if the primary copy trips an ECC fault. A complete extraction from this part therefore captures six regions, not one: the 1 MB array, two boot panels, two configuration blocks, and enough metadata to prove which copy the device was actually running. The family overview explains the swap logic; the practical point is that a read confined to program flash silently discards the oscillator and watchdog setup the board depends on.
Checksum Discipline At The Tail
The last two pages get a verification routine of their own. Erased flash reads as a constant, and a tool that mistakes an erased page for a captured one signs off on a hole. The workflow therefore records, for every page, whether the bytes are erased or written, and compares that map against the image’s own cross-references: code that jumps into an address inside an erased page means either a linker oddity worth flagging or a read that missed something. On a part with sixty-four pages the audit costs minutes, and it is the difference between an image that boots everywhere and one that boots only in the lab.
Protection And Release
The code-protection word is active-low, and once it is cleared the part refuses reads over both ICSP and the 4-wire JTAG port — there is no secondary path through the debug TAP. Write protection, implemented in flash-controller registers rather than configuration fuses, is a boot-time software construct and does not survive an attack on the silicon itself. The only command that lifts code protection is the full chip erase, which is why every engagement starts with ownership verification and a discussion of risk, handled through the contact page before any destructive step is considered.
Where The Image Goes Afterward
Most ECH064 jobs end in one of two deliverables: a verified binary for re-flashing replacement controllers, or a disassembled reference that lets a design house port the CAN application forward. Both depend on the same first step — a read that reaches 0x1D0FFFFF with per-page checksums intact. The 64-pin EF successor of this die is treated on the 1024EFH064 page, where the letter system shifts meaning entirely.