An STM32F103 unlock request must distinguish reusing an erased chip from recovering the original firmware. ST documents a main-Flash mass erase when read protection is removed through the normal protected-to-unprotected transition. That operation cannot serve as a backup of the program it erases. If your only firmware copy is on a working board, make preservation an explicit requirement before any assessment.
This guide explains how to scope owner-authorized STM32F103 firmware recovery, identify the correct device documentation, and define evidence that makes a result useful. Recovery feasibility requires assessment of the actual sample; a family name or a programmer error is insufficient to promise success.
1. Define what your STM32F103 unlock project must achieve
Start with the missing asset and the business outcome. A maintenance team may need a replacement controller for an obsolete machine. A developer may already have a verified binary and only need a reusable device. A failure-analysis project may need to compare the installed firmware against a known release. These are different jobs, even when the enquiry uses the same phrase, STM32F103 IC crack.
- Original firmware recovery: preserve the installed program and identify which additional data must accompany it.
- Reprogramming: use a supplied, authorized firmware image after accepting the consequences of erasure.
- Replacement-board validation: demonstrate agreed functions on the intended hardware, with firmware work scoped separately from the PCB.
Record who authorizes access to the firmware and what use is permitted. Ownership of a board does not, by itself, answer every question about rights to the software it contains. For the wider assessment process, see our authorized IC unlock service.
2. Identify the exact density, package and silicon revision
Photograph every line of the chip marking and both sides of the board. Supply the full order code when known, rather than only “F103” or a development-board nickname. In ST’s medium-density datasheet, STM32F103x8 and STM32F103xB designate 64 KB and 128 KB Flash variants. Package and ordering details must also match the physical sample. See DS5319, revision 20.
| STM32F103 group | Nominal Flash range | Programming manual | Evidence to retain |
|---|---|---|---|
| Low density | 16–32 KB | PM0075 | Full marking and exact datasheet |
| Medium density | 64–128 KB | PM0075 | Order code, package and revision |
| High density | 256–512 KB | PM0075 | Exact capacity and memory coverage |
| XL density | Up to 1 MB | PM0068 | Full part number and both-bank coverage |
ST’s RM0008 reference manual directs low-, medium- and high-density Flash questions to PM0075, and XL-density questions to PM0068. The XL-density manual describes a dual-bank architecture; do not transfer that description indiscriminately to every F103.
Revision evidence matters too. The medium-density ES096 errata, revision 15 maps device markings to revision identifiers and lists revision-dependent limitations. Some marking codes share a revision identifier, so retain photographs alongside any existing tool report. An errata listing is not proof that a particular sample’s protected firmware can be recovered.
3. Read protection: what the documented transition means
PM0075, revision 2, sections 2.3.5 and 2.4 describes protected and unprotected states and distinguishes read protection from page write protection. It does not define an STM32F103 three-level scheme with an irreversible “Level 2” at 0xCC. Such a table must not be imported from another STM32 family.
For XL-density devices, PM0068, revision 2 likewise states that the protected-to-unprotected change mass-erases main Flash. “Unlock succeeded” therefore needs a precise definition: restored programming access does not demonstrate preservation of the old contents.
A connection failure should be recorded as an observation, with the tool version and complete message. It is not sufficient evidence of a particular protection state. Ask the assessor to separate device identification, board condition, communication problems and confirmed protection behavior in the report. Avoid changing option bytes or accepting erase prompts while the original data is the recovery target.
4. Specify what must be preserved before sending the board
A useful intake brief names the exact information needed and the condition in which the sample must be returned. If only one working board exists, say so prominently. Identify any spare or failed boards separately; they are not automatically equivalent references. Keep a dated record of earlier programming, repair or removal attempts.
| Item | Information to supply | Decision it supports |
|---|---|---|
| Main firmware | Known version, existing backups and required address coverage | Recovery target versus available reference |
| Application data | Known calibration, settings or serial-number dependencies | Whether program bytes alone meet the need |
| Other memory devices | Markings and location of any external storage | Separate device assessment and file scope |
| Sample condition | Working state, damage, rework and previous tool messages | Handling constraints and evidence gaps |
| Allowed intervention | Whether removal or destructive analysis may be considered | A clear stop point before irreversible work |
| Acceptance test | Target board revision, fixtures and required functions | A measurable definition of completion |
These are recommended scope questions, not a claim that every memory region is accessible. Mark unknown details as unknown. Do not infer the location of calibration data solely from a generic example online, or assume a file from another board carries the correct unit-specific settings.
If the project also needs schematics, a component list or layout reconstruction, include that requirement in a separate PCB reverse engineering scope. Hardware reconstruction and firmware availability should have separate acceptance criteria.
5. Require evidence with any recovered files
Agree the handoff before assessment begins. A file labelled “STM32F103.bin” leaves too many unanswered questions. The report should connect each delivered file to an identified sample, the covered memory region and the stated outcome. Request:
- A file manifest: sample identifier, file format, byte count, address range and hash.
- Coverage notes: recovered, unavailable and intentionally excluded regions, with gaps stated explicitly.
- Verification evidence: what comparison or consistency check was possible and what it establishes.
- Handling notes: the sample’s returned condition and any agreed changes made during the work.
- Functional results, if ordered: the tested board revision, test conditions and observed behavior.
A matching hash verifies that two files match; it does not establish that a firmware image will operate a replacement assembly. Likewise, a successful power-up is narrower evidence than an agreed functional test. Keep file-integrity checks, memory completeness and board-level validation distinct in the acceptance report.
A compiled binary also does not restore the original source project, comments or build environment. If the objective is to modify the program, discuss analysis or redevelopment separately rather than treating it as an automatic consequence of readout.
6. Questions to resolve before requesting an assessment
Can STM32F103 be unlocked without losing the original firmware?
The documented unprotect transition erases main Flash. A request to preserve original contents needs a separate feasibility assessment of the exact device and sample. This page does not promise a non-destructive recovery method or a successful extraction for every F103.
Does an unlockable chip list guarantee my sample is supported?
No. Use the chip-model enquiry list to identify the part you want assessed. Full markings, revision evidence, sample condition and the requested data determine the actual scope. A listing is not a sample-specific test result.
What determines cost and turnaround?
Request a quotation tied to the confirmed device, available samples, preservation restrictions and verification requirements. Clarify whether assessment, firmware files, external memories and replacement-board testing are included. A generic starting price cannot settle those differences.
What should I send PCB-Copy first?
Send a clear chip-marking photo, the full part number if known, board condition, requested memory regions and your intended use. Include any existing programmer log and state whether this is the only working sample. PCB-Copy can use that brief to discuss an appropriate feasibility scope before you commit the board.
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 reviewWorking 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