What Is Firmware Readout and When Do You Need It?
Firmware readout is the process of extracting the binary contents — program code, calibration data, and configuration bytes — from a microcontroller’s internal flash or EEPROM. Engineers request firmware readout when the original source code is lost, a legacy product needs maintenance, or a prototype must be replicated from the only surviving sample. The extracted .hex or .bin file can then be verified, disassembled, or programmed into a replacement chip.
Our lab performs firmware readout across more than 50 MCU families from vendors including STMicroelectronics, Microchip, Atmel (now Microchip), Texas Instruments, Nuvoton, GigaDevice, and WCH. Every engagement requires proof of IP ownership or written authorization before work begins — a policy we detail on our STM32L432 unlock page and enforce across all projects.
How Does Firmware Readout Work?
The exact technique depends on the chip’s protection scheme. At a high level, our engineers follow a three-stage workflow:
- Feasibility assessment. We identify the MCU part number, read the device ID via JTAG/SWD/ISP, and determine the active protection level (e.g., STM32 RDP Level 1 vs. Level 2, PIC Code-Protect bit, AVR lock bits).
- Protection handling. For chips with recoverable protection, we apply vendor-specific or physical techniques — voltage-glitch attacks, UV-exposure on older OTP devices, or debug-interface exploits — to disable the read-lock without corrupting flash contents.
- Binary extraction & verification. The raw flash image is dumped, checksummed, and compared against a second independent read. We deliver a verified .hex/.bin plus a brief report noting any anomalies (blank sectors, partial writes, ECC flags).
Not every chip is recoverable. Parts with hardware-enforced permanent locks — such as STM32 RDP Level 2 or certain Renesas RH850 devices — physically destroy the debug path, making non-destructive readout impossible. We flag these during the feasibility stage at no charge.
Supported Chip Families for Firmware Readout
The table below lists the MCU families we handle most frequently, along with typical protection levels and realistic success expectations. This is not exhaustive — contact us with your specific part number for a free feasibility check.
| Vendor | Family / Example Parts | Common Protection | Readout Success |
|---|---|---|---|
| STMicroelectronics | STM32F1/F4/L4, STM8L/S | RDP Level 0–2 | High (Level 0–1); not feasible at Level 2 |
| Microchip (PIC) | PIC16F1509, PIC18F, dsPIC33FJ | Code-Protect (CP) bit | High for most 8-/16-bit parts |
| Microchip (AVR) | ATmega16/32, ATtiny13 | Lock bits LB1/LB2 | High for classic AVR; limited on newer AVR-Dx |
| Atmel 8051 | AT89C52, AT89S51 | Lock Bit 1–3 | High for LB1/LB2; case-by-case for LB3 |
| Texas Instruments | MSP430F149, MSP430FR5969 | JTAG fuse, BSL password | High for F-series; FRAM parts require extra steps |
| Nuvoton | N76E003, NUC131 | Security lock, ISP password | High for most 8051-core and Cortex-M0 parts |
| GigaDevice | GD32F103, GD32F303 | SWD read-protect (similar to STM32 RDP) | High for Level 0–1 |
| WCH | CH32V307, CH552G | Read-protect bits | Moderate to high depending on silicon revision |
| Silicon Labs | EFM8BB series | Security page lock | High for most EFM8 variants |
For Microchip PIC devices, our PIC16F1509 unlock page explains the CP-bit recovery process in detail. AVR engineers can review specifics on our ATmega16 unlock page, while TI MSP430 projects are covered under MSP430F149 unlock.
What Affects the Cost of Firmware Readout?
Pricing depends on three variables: protection complexity, chip availability, and urgency. Below are the ranges our clients typically encounter.
| Complexity Tier | Examples | Typical Cost (USD) | Turnaround |
|---|---|---|---|
| Low — no protection or trivial lock | Unprotected STM32F103, ATmega328P with LB1 only | $300 – $500 | 3–5 working days |
| Medium — standard code-protect | PIC16F with CP, MSP430 with JTAG fuse, AT89C52 LB2 | $500 – $1,200 | 5–8 working days |
| High — advanced or multi-layer protection | STM32 RDP-1 with PCROP, dsPIC33FJ with dual-partition boot | $1,200 – $3,000+ | 7–15 working days |
| Research / novel silicon | New-revision WCH or GD32 parts not previously profiled | Quoted after feasibility | 10–20 working days |
Feasibility assessment is free. If we determine the chip cannot be read without destroying data, you owe nothing. Rush service (≤3 days) is available for low- and medium-tier jobs at a 40–60 % surcharge.
Firmware Readout vs. Full IC Unlock — What’s the Difference?
The terms are often used interchangeably, but there is a practical distinction. Firmware readout refers specifically to extracting the flash/EEPROM binary. IC unlock is the broader process that may also include disabling write-protect, recovering fuse configurations, or extracting OTP calibration data beyond the main program space.
For example, on a GD32F103 unlock job, the client needed not only the 256 KB flash image but also the option-byte configuration and the factory-programmed unique device ID — all of which fall under IC unlock but go beyond a simple firmware dump.
If your goal is to program an identical replacement chip, you typically need the full IC unlock scope. If you only need the binary for disassembly or audit, a firmware readout alone may suffice.
Authorization and Legal Requirements
Firmware readout touches intellectual property directly. We operate under strict ethical guidelines:
- Proof of ownership. You must demonstrate that you own the design, hold a license, or have written authorization from the IP holder.
- NDA coverage. Every project is executed under a mutual NDA. We do not retain copies of extracted binaries after delivery unless the client requests archival.
- Legitimate use cases. Legacy maintenance, end-of-life component replacement, failure analysis, and authorized second-sourcing are the scenarios we support. We decline requests that lack clear authorization documentation.
These policies protect both parties. Clients working with sensitive defense or medical firmware can request additional security measures — encrypted file delivery, on-site extraction, or witness-supervised sessions.
Deliverable Formats and Verification
After firmware readout, you receive:
- Raw binary (.bin) and Intel HEX (.hex) files.
- Fuse/option-byte configuration report (where applicable).
- SHA-256 checksum of the extracted image.
- Brief technical report: chip marking photo, protection level encountered, extraction method category (non-destructive / semi-invasive), and any anomalies.
We perform a minimum of two independent reads and compare checksums before delivery. If the two reads differ — which can happen with degraded flash cells on older parts — we flag the discrepant sectors and provide both images so you can make an informed decision.
Common Failure Modes and Honest Limitations
Firmware readout is not guaranteed on every chip. Here are the scenarios where extraction fails or produces incomplete data:
- Permanent protection. STM32 RDP Level 2, certain Infineon TriCore HSM-locked parts, and Renesas TSIP-enabled devices fuse the debug interface permanently.
- Flash degradation. MCUs that have been in service for 15+ years or exposed to high temperatures may have bit-rot in flash cells, resulting in corrupted sectors.
- Decapped-die damage. Semi-invasive techniques on BGA or WLCSP packages carry a small risk of bond-wire damage. Our current yield on decap-dependent jobs is above 90 %, but it is not 100 %.
- Encrypted firmware. Some newer Cortex-M33 parts (e.g., STM32L5 with TrustZone) encrypt flash contents at rest. Even if read-protection is bypassed, the dump is AES-encrypted and unusable without the device key.
We communicate these risks during the feasibility stage. If a chip falls into an unrecoverable category, we recommend alternative paths — sourcing NOS (new-old-stock) parts, contacting the original silicon vendor for a replacement binary, or redesigning around a modern MCU.
How to Request a Firmware Readout
Getting started takes three steps:
- Submit your chip details. Provide the full part number (including package suffix and revision), a photo of the chip marking, and a brief description of why you need the readout.
- Receive a feasibility report. Within 1–2 business days, our engineers confirm whether readout is possible, the expected cost, and the turnaround time.
- Ship the device. Send one or more sample chips (we recommend at least two for redundancy). We handle worldwide logistics with tracked shipping and customs-friendly documentation.
Check feasibility for your project
Send the chip marking or board details and tell us what you need to recover. Add clear photos if available.
Request a feasibility reviewCan firmware readout recover data from a chip with erased flash?
No. Firmware readout extracts what is currently stored in flash or EEPROM. If the chip has been bulk-erased (all 0xFF), there is no residual data to recover. Unlike magnetic media, flash memory does not retain “ghost” images of prior writes after a full erase cycle.
Do I need to desolder the chip before sending it?
Not necessarily. For chips with accessible JTAG, SWD, or ISP headers, we can read firmware with the MCU still soldered to the PCB. If the board lacks debug headers or uses a BGA package that requires decapping, we will desolder the chip ourselves. Sending the entire board is often the safest option to avoid ESD or mechanical damage during removal.
Is firmware readout legal?
Yes, when performed on firmware you own or are authorized to access. Common legal scenarios include recovering your own lost source code, maintaining legacy equipment you operate, and failure analysis. We require proof of ownership or written authorization before starting any project, and all work is covered by NDA.
What if the chip is damaged or the package is cracked?
We can attempt readout on physically damaged chips, but success depends on whether the die and bond wires are intact. Cracked packages with an undamaged die often yield full extractions. If the die itself is fractured or corroded, recovery is unlikely. Send photos and we will assess feasibility at no cost.
How does firmware readout differ from JTAG boundary scan?
JTAG boundary scan tests pin connectivity and board-level faults — it does not read internal flash memory. Firmware readout uses the debug interface (which may travel over the same JTAG pins) in a different mode to access the MCU’s memory map. Some chips disable flash access over JTAG when protection is active, requiring additional techniques beyond standard boundary scan.
Related Chip Unlock Services
If you already know your target MCU, jump directly to the relevant page for chip-specific feasibility details, protection notes, and pricing:
- Nuvoton N76E003 flash extraction — popular in low-cost IoT and consumer devices.
- WCH CH32V307 code recovery — RISC-V core with multiple protection revisions.
For chips not listed here, submit your part number through our feasibility form and receive a response within 1–2 business days.
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quote