Somewhere below 16 KB of SRAM, a microcontroller stops being a display controller. The PIC32MX130F064B sits just above that line: 64 KB of program flash, 16 KB of SRAM, and a parallel master port that can drive external devices at bus speed. Products built on it tend to use the extra memory for exactly that — frame buffers, line buffers, character generators — and that choice is what makes its recovered images different from the smaller members of the family.
The Memory That Never Appears In The HEX
Flash contents survive power loss; SRAM does not. A recovery reads the 64 KB program array at 0x1D000000 through 0x1D00FFFF and the 3 KB boot bank at 0x1FC00000, including the DEVCFG words at the top of the boot partition. What it cannot read is the 16 KB of SRAM, because it is empty the moment the power drops. Yet the firmware’s structure is organized around that SRAM: where the frame buffer starts, how the line buffers are carved, which regions the parallel master port streams from. Reading the image well means recognizing those regions by their access patterns — base addresses loaded into DMA descriptors, pointer arithmetic aligned to buffer boundaries, loops bounded to buffer sizes.
That is reconstruction work, not capture work. The capture is routine; the interpretation is where the 130F064B earns its keep. A customer who needs the display behavior reproduced — not just the HEX file archived — is buying the second half.
The Parallel Master Port Signature
PMP is the family feature that separates graphics products from appliance products. In firmware it leaves a loud fingerprint: dedicated initialization for the port, interrupt service routines that push or pull bytes at line rate, and configuration of address latching and strobe timing. On a recovered image, that cluster identifies the part’s role even before the application logic is disassembled. The same signature tells the analyst what the missing SRAM contents were doing — a line buffer at a known address, a double-buffered frame area, a glyph table copied out of flash at boot.
Bootloader-bearing images are also common here. Three kilobytes is small, but a serial or USB-style loader lives in it comfortably, and the boot bank’s separate erase domain means the loader survives application updates. The reading process captures both partitions as distinct regions, because a merge would make the loader indistinguishable from the application.
Configuration Words And The Display Periphery
The four DEVCFG words sit in the last page of the boot flash and decide how the part starts: oscillator and PLL selection for the pixel clock, watchdog policy, debug channel, and the code-protect bit — DEVCFG0 bit 28, active low, so a programmed zero arms the protection that blocks external reads of both partitions. Once armed, the only exit documented by Microchip is the chip erase command, which blanks the part. That ordering — read first, discuss protection second — is not conservatism; it is the difference between a deliverable and a cautionary tale.
Write-protect fields in the same register guard pages against modification during execution but leave external reads untouched, so “the part is write-protected” is never a reason to stop.
Beyond The Small Packages
The 130 family does not stop at 44 pins: H and L packages extend it to 64 and 100 leads, carrying the same core densities into larger I/O counts. That matters to recovery for one reason — archived documentation and replacement quotes drift across the package suffixes, and a board designed around the 64-pin H version is not served by a fixture quoted for the 28-pin B. The device ID disambiguates the die; the lead count settles the rest. For the small-package job described here, the practical note is simpler: quote from the part in hand rather than the family table, and the who we are page describes how that policy is applied job by job.
What A Complete Deliverable Looks Like
Three regions, two independent captures each, compared word by word: program flash, boot bank, configuration. The device ID is read back to pin the density — this part shares its 28-pin footprints with the 110F016B and 120F032B, and stock mix-ups are not hypothetical. Erased words read all ones, and the report maps the boundary between live code and padding so a rebuild knows exactly how much of the array was in use. The chip extraction analysis service adds the interpretation layer: buffer maps, PMP timing constants, the display pipeline as the firmware actually implements it.
Who Asks For This Part
Two audiences, usually: product owners who lost the source to a display-bearing design and need the firmware plus its data layout, and engineers porting the product who need the PMP timings and glyph tables rather than a HEX to drop into a new build. Both start the same way — the part, the board, or both — and the NDA page sets the terms before anything is shipped or read. The 130F064B is a well-behaved subject; the discipline is all in knowing what its 16 KB of SRAM was doing, because that is the half of the product the HEX file never contained.
For the wider branch, the PIC32MX extraction index lists every part with its geometry and package.