CAN nodes are terse machines: they listen, they arbitrate, they transmit frames on a schedule someone tuned years ago. The PIC32MZ2048ECH064 is a frequent heart for such nodes — 2 MB of program flash, dual CAN 2.0B controllers, an Ethernet MAC often unused, and a firmware image whose most valuable bytes are not the C code at all but the message tables surrounding it. Dumping this part well means treating those tables as the deliverable.
Where The Listings Live
The program array spans 0x1D000000 to 0x1D1FFFFF, erased in 16 KB pages. Application builds typically place CAN configuration in one of two habits: compiled-in constant structures near the code that consumes them, or parameter pages near the top of the array, updated in the field when a node is re-addressed. Both habits are visible in a read-back image — constant structures sit as dense, regular listings; field-parameter pages occupy whole pages with version stamps and erased gaps. A review that only checks code-region checksums misses the second habit entirely, which is why dumps from this part are verified page by page across all 128 pages, with the top quarter receiving special attention.
The Die And The Letter
The H in the part number marks the EC family’s CAN-equipped, crypto-free feature set — same 200 MHz microAptiv core as its siblings, five-stage pipeline, 16 KB instruction and 4 KB data caches, DSP accumulators, microMIPS encoding, no floating point unit, and 512 KB of SRAM behind the 2 MB array. Around the flash, two 80 KB boot panels hold startup code and the configuration tails — on this generation a dedicated code-protection word plus an alternate mirror the hardware falls back to on ECC faults. The family overview keeps the memory map straight across all twenty variants.
What A Good Dump Contains
Beyond the raw regions, a CAN-node deliverable earns its keep with parsed content: message-object listings rendered as ID, mask, DLC and direction listings; scheduler intervals extracted from timer setup; and the diagnostic identifiers the node answers on. Clients rebuilding discontinued nodes care about these listings more than about the binary itself — they are the interface contract no datasheet records. Our invasive extraction service reports them alongside the verified binary.
Bus loading analysis rides along when the client wants it: the recovered code’s transmit scheduling, combined with the timing constants, indicates how much of the bus budget the node consumes. On fleets near saturation, that estimate decides whether the recovered node can be re-hosted as-is or needs its schedule trimmed.
Bit Timing And The Census
CAN brings one configuration family the report always extracts: bit-timing constants. Segments, sample points and prescalers are compiled into the image as numbers that must match the transceiver and the bus the node joins, and they are the first thing a re-hosted node gets wrong when a replacement board uses a different crystal. The census lists the timing values for both controllers, the acceptance filters, and the error-state handling the application installed. Clients integrating a recovered node into an existing fleet compare these numbers against the fleet’s other nodes before the first connection, a two-minute check that prevents the kind of bus-wide disruption that gives firmware recovery a bad name.
Protection On A Node That Must Keep Working
One active-low code-protection word guards the array; once cleared, ICSP and the 4-wire JTAG port lock together and only a full chip erase releases them — an event that also erases the message listings the client wants. Node boards are frequently installed and running when the recovery request arrives, which adds an operational question: whether the dump can happen on a spare or must wait for a maintenance window. Both paths start with ownership verification through the contact desk.
A 100-pin sibling with the same die appears on the 2048ECH100 page, where the letter system’s marketing-versus-silicon distinction gets its own treatment.