Secure chip is a phrase that arrives on purchase orders before anyone has looked at the configuration words. On the PIC32MX150F128B the security story is exactly one bit long. DEVCFG0, bit 28, is the code-protect switch, and it is active low: a programmed zero arms it, the unprogrammed default leaves the part wide open. Everything a customer needs to know about “is this chip secure” follows from reading those four bytes at the top of the 3 KB boot bank.
What The Bit Does
When code protect is armed, the flash controller refuses external reads of both partitions — the 128 KB program array from 0x1D000000 to 0x1D01FFFF and the 3 KB boot flash at 0x1FC00000. There is no degraded readout, no half-access mode, no way to page through the array a region at a time. The Microchip programming specification states the only sanctioned exit: the chip erase command, which blanks both partitions and returns the part to factory state. The firmware is the price.
That is why the sequencing rule in the same specification matters: a programmer enables code protect last, after the image has been verified. Production lines that follow it ship parts whose protection is real and whose firmware is confirmed; lines that arm the bit before verification ship parts whose contents were never checked and can now never be checked.
What It Does Not Do
Three neighboring mechanisms get confused with code protect, and each behaves differently. Program write protect guards selected pages of the program array against modification during code execution; it does not stop an external reader, so a “write-protected” part is fully readable. Boot write protect does the same for the 3 KB bank. The debug channel can be configured away from its default pins, which inconveniences a debugger but leaves the programming interface untouched. Treating any of these as the security feature produces confident wrong answers in both directions — parts declared locked that read like a book, and parts declared open that are not.
The distinction is worth stating in a quote because it changes the work: a write-protected 150F128B is a one-hour job; a code-protected one is a conversation about what the customer needs the firmware for and whether the protection was theirs to lift.
Write Protection, In Its Own Words
The write-protect fields deserve a paragraph of their own because they are the most misread bytes in the register. The program write protect bits encode, as a one’s complement, how many pages of the program array are shielded from modification while code executes — the shield builds from the bottom of the array, where the application lives, and the all-ones setting disables the feature. Boot write protect does the same for the 3 KB bank. Neither field says anything about reading; a production line that arms them ships parts whose firmware is safe from stray writes and fully visible to an external reader. That asymmetry is the whole reason the register read comes first: two parts with identical markings can differ in these bytes, and the difference decides the shape of the job before any fixture is built.
The same register carries the debug channel selection, which steers the 4-wire JTAG port away from its default pins. Designers use it to free I/O on crowded boards; recoveries meet it as a part that ignores a debugger wired to the standard pins. The programming interface is unaffected — the two-wire ICSP path converts to the four-wire JTAG machinery internally, and it listens on the pins the configuration words select, not the ones convention suggests.
The Part Under The Bit
Above the security discussion, the 150F128B is the largest 1XX-family member in the small packages: 128 KB of flash, 32 KB of SRAM, 28 pins in SOIC, SSOP, SPDIP or QFN, and the full peripheral set — two UARTs, two SPI/I2S ports, two I2C buses, parallel master port, five timers, 10-bit converter at 1 Msps. No USB: that begins with the 2XX parts, the smallest being the 210F016B. The M4K core runs to 50 MHz at 83 DMIPS, and MIPS16e encoding is available to a compiler that needs the density.
Erased flash reads all ones, live code ends at a discoverable boundary, and production images at this density usually run close to the ceiling with a spare sector for a revision table. Two independent captures of both partitions, compared word by word, plus a device ID read to pin the die — that is the verification standard, and the reading process page details it.
Answering The Question In The Right Order
The work sequence for a “secure chip” inquiry is short: read the device ID, read the DEVCFG words, and only then describe what is possible. If bit 28 is unprogrammed, the image comes back complete — both partitions and the configuration page — usually within days. If it is programmed, the honest answer is that the sanctioned path destroys the firmware, and the alternatives are fewer than most marketing copy suggests. The FAQ covers the follow-up questions, and the NDA page governs what is shared either way. A one-bit security model is easy to describe; describing it accurately, before work starts, is what separates a report from a guess.
Geometry for the rest of the branch, including the 100-pin exception, is on the PIC32MX overview page.