Short answer: most classic Microchip 8-bit parts are readable. The PIC10F, PIC12F, PIC16F, PIC16C and PIC18F families are the everyday work of Microchip IC unlock, and the AVR line Microchip acquired with Atmel — ATtiny and ATmega — is equally routine. dsPIC30F/33F and PIC24F/24H are usually feasible. PIC32MZ with an active boot flash configuration and the newer SAM parts with secure boot are where the honest answer becomes “send it in and let us look.”
Why engineers come to us with a locked Microchip part
The pattern is almost always the same. A machine from 2004 still runs a production line, the PIC18F452 on the control board has failed, the engineer who wrote the firmware retired two companies ago, and nobody can find the hex file. Or a customer has the hex but not the source, and the part itself is now NRND, so the code needs to move to a current device.
Those are the jobs we do: firmware recovery for a design you own, keeping legacy equipment alive, migrating off an obsolete part, and failure analysis on a returned board. You need to hold the rights to the design or have written authorization from whoever does, and every project runs under NDA before a board or chip ships to us. That’s the whole legal conversation as far as this page goes.
Microchip families we handle, family by family
8-bit PIC — the bulk of the work
PIC12F, PIC16F and PIC18F parts make up most of the Microchip IC unlock requests we see. The security model on these devices centers on configuration-word protection bits that gate ICSP readback of program memory and, separately, data EEPROM. Older mid-range parts and the PIC16C OTP series are generally straightforward. Later PIC18F K-series and J-series parts with block-level protection take more characterization work.
Practical notes that affect your specific part:
- Data EEPROM matters. On many designs calibration constants, serial numbers or run-hour counters live in on-chip EEPROM, not flash. Tell us if you need that content too, because a program-memory-only read may leave you with firmware that boots into an error state.
- Config words are part of the deliverable. A hex dump without the correct oscillator, watchdog, brown-out and MCLR settings won’t run. We capture and report them.
- OTP parts can’t be re-flashed. For PIC16C devices, recovery means we hand you the image and you program a replacement part or an equivalent flash device.
- Package matters. A DIP or SOIC part is easier to handle than a QFN that has to come off a board with a hot-air rework station without cooking the neighboring electrolytics.
dsPIC30F, dsPIC33F/EP and PIC24
These 16-bit parts show up in motor control, power conversion and instrumentation. dsPIC30F4011 and dsPIC33FJ128 are common. Feasibility is generally good, but the code protection segments — boot segment, secure segment, general segment — behave differently depending on how the original designer configured them. A part with only general-segment protection enabled is a different job from one with the boot segment locked and the write-protect bit set. We determine which case you have during evaluation, not before.
AVR: ATtiny, ATmega, AT89
Since the Atmel acquisition these are Microchip parts too, and they’re a big share of our volume. AVR security rests on lock bits (LB1/LB2) plus the boot lock bits on parts with a bootloader section. The classic devices — ATmega8 code readout, ATmega16, ATmega32, ATmega128, ATmega328/328P and the ATtiny13/85 — are well-trodden ground. Less common parts like the ATmega169 with its LCD controller are also usually workable.
One AVR-specific warning worth stating plainly: on these devices a chip erase clears lock bits and flash together. That means there is no path that involves “just erasing the lock bits” and reading afterward. Anyone telling you otherwise doesn’t understand the part. Recovery has to preserve the array.
PIC32 and SAM (ARM Cortex-M)
PIC32MX is often feasible. PIC32MZ with boot flash protection configured and code-protect fuses set is significantly harder, and we will tell you if we think the odds are poor rather than take the job and bill you for a failure. The SAM D and SAM L families, plus anything with a factory-provisioned secure bootloader or a debug access port permanently disabled, sit in the same category. On modern ARM parts the honest comparison point is how STM32 read-out protection levels behave — Level 2 on ST silicon and its Microchip equivalents represent a genuine wall, not a speed bump.
Serial memory and CPLD
Microchip also owns a large serial EEPROM and flash catalog, plus the ATF15xx CPLD line from Atmel. 24-series I²C EEPROMs, 25-series SPI flash and 93C46 Microwire EEPROM reads are frequently part of a larger board recovery — the MCU firmware alone rarely tells the full story when configuration data lives in an external chip.
How difficulty actually varies across Microchip parts
| Family | Typical protection mechanism | General feasibility |
|---|---|---|
| PIC10F / PIC12F / PIC16F | Config-word code protect bits, separate EEPROM protect | Usually feasible |
| PIC16C (OTP) | Config protect, one-time programmable array | Usually feasible; replacement part needed |
| PIC18F (classic) | CP/WRT/EBTR bits, block granularity | Usually feasible |
| PIC18F J/K series | Block protection, expanded config | Case by case |
| PIC24F / PIC24H / dsPIC30F / dsPIC33 | Segmented code protection (BS/SS/GS) | Usually feasible, depends on segments |
| ATtiny / ATmega | Lock bits, boot lock bits, fuse settings | Usually feasible |
| PIC32MX | Code protect fuse, boot flash | Case by case |
| PIC32MZ / SAM D / SAM L | Boot protection, DAP lock, secure boot | Often difficult, sometimes not feasible |
“Case by case” is not us hedging. Two boards carrying the same part number can be different jobs because the original firmware author configured protection differently, and because die revision matters — a 2009 silicon rev and a 2019 rev of the same catalog number are not always the same problem.
What happens to your chip in the lab
- Identification. We read the full topside marking, including the revision and date code, under a stereo microscope. Remarked and relabeled parts are common in field-repaired equipment, so we confirm the die matches the marking before quoting.
- Non-invasive characterization first. We probe the programming interface — ICSP on PIC parts, ISP or JTAG on AVR — and record exactly which memory regions respond, which return blank or scrambled data, and how the device behaves at the edges of its supply and clock specification. This step alone often resolves feasibility.
- Method selection. Based on what we learned, the job is routed to a non-invasive route, a semi-invasive route, or declared not feasible. We tell you which before proceeding, because the routes differ in cost and in whether your sample survives.
- Extraction. Program memory, data EEPROM where applicable, and the configuration/fuse settings are captured together.
- Verification. This is the part that separates a real result from a hex file of noise. We program a blank part of the same type with the extracted image and configuration, drop it into a test fixture or your original board, and confirm it runs. We also check the image for sane structure — a plausible reset vector, an interrupt table where the architecture says one belongs, recognizable string and lookup-table regions rather than uniform garbage.
If verification fails, you don’t get a bill for a successful unlock. That’s the working rule, and it’s why the evaluation step exists.
What to send us, and what comes back
Feasibility assessments live or die on the quality of what you send. To get a real answer instead of a generic one:
- A clear, in-focus photo of the chip’s top marking — every character, including revision and date code. Sharp macro shot, even lighting, no flash glare across the laser mark.
- Photos of both sides of the board on a dark, non-reflective background, whole board in frame, plus the board’s overall dimensions.
- The package type and whether the part is still soldered down or already removed.
- How many identical samples you can supply. Two or three of the same part meaningfully improves the odds on a hard case, because it lets us characterize on one and preserve the others.
- One line on what you need: raw binary only, binary plus fuse/config settings, pre-programmed replacement chips, or a full recovery package that also includes the board.
- Any context you have — what the board does, whether the MCU talks to an external EEPROM, whether the equipment still powers up.
Back from us: a feasibility judgment naming the likely route, a lead time, and a price. Simple 8-bit PIC and AVR parts are typically a matter of days. Segmented dsPIC parts and anything needing sample preparation run longer. Cost is driven by family and protection depth, whether decapsulation is involved, how many samples you send, and whether you want programmed replacement chips or files only — not by a fixed menu, which is why we quote per part rather than publish a table of numbers.
If the firmware is only half the problem and the board layout is gone too, we can run
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.Working on a board like this?
Related reading
