Two members of this family carry 256 KB of program flash, and they are not interchangeable. The PIC32MX230F256x pairs the density with 16 KB of SRAM; the PIC32MX270F256D pairs it with 64. Same flash, four times the working memory, and the firmware written for each is a different animal. Recovering a 270F256D image means reading a part whose code was organized around buffer abundance — and the abundance shows.
What 64 KB Of SRAM Invites
Memory that large on a 28- or 44-pin part gets spent, not saved. Frame buffers move from fragments into full planes; audio pipelines double-buffer end to end; protocol stacks keep whole message pools resident; file systems cache directories. None of it appears in the flash image directly — SRAM is empty at power-off — but the code is built around it: initialization sequences that carve fixed regions, DMA descriptors sized to plane boundaries, pointer arithmetic aligned to allocations the linker assigned. A reader who knows what 64 KB of SRAM was doing can reconstruct the memory map from the image; a reader who assumes the 16 KB sibling’s layout reconstructs fiction.
The distinction also matters commercially. Products migrate between the two densities when displays or USB features arrive, and a source archive labeled for one often describes a board running the other. The device ID read settles which die is present; the 130F064B page covers the SRAM-threshold question at the family’s other crossing point.
The Part In Detail
The 270F256D carries 256 KB of program flash from 0x1D000000 to 0x1D03FFFF, 64 KB of SRAM, and the full 2XX peripheral set: full-speed USB 2.0 with device, host and OTG modes, I2S audio in all four framing modes, parallel master port, four general DMA channels plus two dedicated to USB, two UARTs, two SPI/I2S ports, two I2C buses, five timers, 10-bit converter at 1 Msps, CTMU, RTCC, and the peripheral pin select matrix. The M4K core runs to 50 MHz and 83 DMIPS. Boot flash is the family-standard 3 KB at 0x1FC00000 through 0x1FC00BFF — 256-word page erases and 32-word program rows in the program array — with the DEVCFG words in the boot partition’s last page. Note that the 100-pin 512 KB sibling plays by different geometry rules; the 270F512L page covers that.
The 28-Pin Sibling And The BOM Drift
The 270F256B is the same die in 28 pins, and between the two packages the family’s smallest and largest small-scale footprints carry identical memory. BOM drift across them is routine: a product line starts on the 28-pin part, grows a display or a sensor bank, and migrates to 44 pins without changing the part number’s density field. Archives then hold HEX files for both, marked identically except for the package letter — and sometimes not even that. The device ID does not distinguish the packages either, since the silicon is the same; the lead count and the board do. Quoting from the part in hand, with its marking and its pin count, is the only quote that survives contact with the actual board.
Encrypted? The Register Says Otherwise
Inquiries about this part often arrive framed as encryption recovery, and the frame is wrong: like the rest of the generation, the 270F256D has no flash cipher — the array stores plain executable words. What it has is code protect, DEVCFG0 bit 28, active low. Armed, it blocks external reads of both partitions; the only exit documented by Microchip is the chip erase that destroys the image. Reading the DEVCFG words before quoting converts the vocabulary question into a register answer, which is the discipline the copy protection page describes. Write-protect fields do not block reads and never justify stopping.
What The Buffer Map Is Worth
A 64 KB SRAM reconstruction has a specific deliverable: the memory map. Which addresses held the frame plane, where the audio ring lived, how the protocol pools were carved, what the DMA descriptors referenced — each recovered from the initialization code and the pointer arithmetic, and each useful the moment the product needs porting, extending or debugging. Engineers who inherit such products without documentation spend weeks inferring the map; a recovery hands it over with the HEX. The map is also the fastest way to verify the capture: regions that the firmware initializes but the flash never populates are exactly the regions the map should explain. When the two agree, the reconstruction is honest.
The Read
Two independent captures of both partitions, compared word for word; device ID read back to pin the die; configuration words decoded and cross-checked. The live-code boundary is mapped through the erased tail. For a buffer-heavy product the report adds the layer that matters: the reconstructed SRAM map — where the planes sat, what the DMA channels fed, how the pools were laid out — so the customer owns the product’s memory architecture, not merely its instruction stream. The reading process page covers capture mechanics; the firmware extraction overview describes packaging; the FAQ answers what arrives before a purchase order. Same flash as its cheaper sibling; a different product entirely in what the code does with the room.
The other parts in this branch are indexed on the PIC32MX family page with their flash sizes and packages.