Eighteen part numbers, one core. Every PIC32MX in the 1xx and 2xx lines runs the same MIPS M4K pipeline at 40 or 50 MHz, and every one of them protects program flash with a single configuration bit that has no fuse and no backup battery behind it. Nothing about the protection model changes as you walk up the table. What changes is the geometry, and geometry decides how a read-out is planned rather than whether one is possible.
This page is the index for the family. Each part below links to its own write-up, because the useful detail is per-device: which package is on the board, where the configuration words sit relative to the array, and what a dump looks like when part of it was never populated.
Reading the part number
A PIC32MX250F128C is not a 250 MHz device, and none of the digits is a clock speed.
| Segment | Meaning |
|---|---|
1 or 2 |
family branch. The 2xx branch carries a full-speed USB OTG block; the 1xx branch does not. |
250 |
feature tier inside the branch, covering timers, DMA channels and analog inputs. |
F |
flash program memory. Every MX part is flash, so there is no OTP variant to plan around. |
128 |
program flash in KB. |
B C D L |
package: 28 pin, 36 pin VTLA, 44 pin, 100 pin. |
The package letter usually matters more than the tier number when a board arrives, because it settles both the fixture and the page size. A 36-pin VTLA device and a 44-pin TQFP device can share a tier and still differ in ways that change how a dump is addressed.
Two geometries, not eighteen
Program flash is organised into rows and pages, and the family splits cleanly in two.
| 28 / 36 / 44-pin devices | 100-pin 512L devices | |
|---|---|---|
| Row | 32 words (128 B) | 128 words |
| Page | 256 words (1 KB) | 4 KB |
| Boot flash | 3 KB, ends at 0x1FC00BFF |
12 KB, ends at 0x1FC02FFF |
Program flash begins at 0x1D000000, so the last valid address follows capacity directly: 16 KB ends at 0x3FFF, 32 KB at 0x7FFF, 64 KB at 0xFFFF, 128 KB at 0x1FFFF, 256 KB at 0x3FFFF, and 512 KB at 0x7FFFF.
An error here does not raise an exception. It returns an image that reads cleanly, verifies against itself, and fails on the bench because the top page was addressed with the wrong stride.
Protection is one bit, low-active
The code-protect bit sits in DEVCFG0 at bit 28 and is active low, so writing zero enables it. Once set, the programming interface stops returning the array. There is no partial unlock and no key sequence worth planning around.
The only documented way to clear it is a full chip erase through the MCHP_ERASE sequence, and that erases the very memory you wanted to read. The lock is therefore not a password but a decision that can only be reversed by losing the data.
Two neighbouring bits get confused with it. PWP and BWP are write-protect bits: they stop a programmer from writing and do nothing about reading. A device with write protection and no code protection reads out normally.
Microchip’s own production flow recommends verifying the image before the protect bit is set. When a board arrives already protected, that flow has run to completion, and the first question is no longer what the device contains but which route reaches the array. That distinction is covered in microcontroller copy protection.
What a complete image has to contain
A dump covering only the main array is not a firmware image. Three regions live outside it.
– Configuration words at the top of configuration space, holding oscillator selection, watchdog behaviour and the CP bit itself. Without them a rebuilt board starts on the wrong clock. – Boot flash, which carries startup code and, where supported, the programming executive. – The flash-simulated data area, where calibration constants and counters usually live. MX parts have no real EEPROM, so anything behaving like EEPROM is a region inside program flash with a 1 KB erase page.
An image missing the third item boots and then misbehaves, which is harder to diagnose than one that does not boot at all. The general method behind this check is in MCU reading.
The eighteen parts
| Part | Flash | USB | Pins | Read-out focus |
|---|---|---|---|---|
| PIC32MX110F016B | 16 KB | no | 28 | what the 16 plus 3 KB actually accounts for |
| PIC32MX120F032B | 32 KB | no | 28 | same footprint, different density |
| PIC32MX130F064B | 64 KB | no | 28 | where the 16 KB SRAM threshold bites |
| PIC32MX150F128B | 128 KB | no | 28 | what the CP bit really asserts |
| PIC32MX150F128C | 128 KB | no | 36 VTLA | fixture work for the smallest package |
| PIC32MX150F128D | 128 KB | no | 44 | analog-heavy applications |
| PIC32MX210F016B | 16 KB | yes | 28 | why there is no EEPROM to read |
| PIC32MX210F016C | 16 KB | yes | 36 VTLA | USB descriptor tables |
| PIC32MX210F016D | 16 KB | yes | 44 | what locked actually means |
| PIC32MX220F032B | 32 KB | yes | 28 | three regions, one binary |
| PIC32MX220F032C | 32 KB | yes | 36 VTLA | 40 versus 50 MHz parts |
| PIC32MX220F032D | 32 KB | yes | 44 | mixed MIPS16e and MIPS32 code |
| PIC32MX230F064B | 64 KB | yes | 28 | DMA topology in the image |
| PIC32MX250F128B | 128 KB | yes | 28 | what fills 128 KB |
| PIC32MX250F128C | 128 KB | yes | 36 VTLA | the absence of an encryption engine |
| PIC32MX250F128D | 128 KB | yes | 44 | a checklist for a complete image |
| PIC32MX270F256D | 256 KB | yes | 44 | what doubles with SRAM |
| PIC32MX270F512L | 512 KB | yes | 100 | the geometry exception |
Choosing where to start
Three questions narrow the route faster than a datasheet dive.
1. Does the board have USB? If it does, the part is a 2xx device, and the descriptor tables in firmware are often the reason the image is wanted at all. 2. How much SRAM? It decides how much of the application can be relocated, which matters when the goal is a working clone rather than an archive. 3. Is the part already protected? If it is, no in-circuit attempt will return data, and the work moves to semi-invasive IC extraction.
A last point about expectations. These parts have no encryption engine, no key storage and no secure boot chain, so there is nothing cryptographic to defeat. The obstacle is the interface, not the mathematics, and the interface fails closed the moment the protect bit is written.
If a board is already open and the question is whether the die is worth working on, chip extraction analysis covers the decision. If the part is known and the goal is a reproducible image, the services page lists what a deliverable contains, and contact is the place to send a part number and a package photo.