Most Fujitsu IC unlock jobs land on one of four families: the 8-bit F2MC-8L parts (MB89, MB95 series), the 16-bit F2MC-16LX parts (MB90F series), the 32-bit FR cores (MB91F), and the later Spansion/Cypress-branded FM3 and FM4 devices that inherited the Fujitsu MCU line. Feasibility varies a lot across those four groups, and it depends more on the specific die revision than on the family name. Send us the exact top marking and we’ll tell you where your part sits.
Why people ask about Fujitsu parts specifically
Fujitsu exited the microcontroller business in stages — the MCU line went to Spansion in 2013, then to Cypress, then to Infineon. That means nobody is issuing new errata, no factory programming support exists, and the original toolchains (Softune Workbench, the old ICE pods) are hard to find in working condition.
So the boards we see are almost always legacy industrial gear: elevator controllers, HVAC head units, automotive body modules, textile machinery, older instrumentation. The customer owns the product, the engineer who wrote the code left a decade ago, and the archived hex file was on a machine that no longer boots.
That’s the normal case for Fujitsu IC unlock work — recovering firmware you already own so a discontinued product can keep shipping or keep being repaired. You need to hold the rights to the design, and everything we handle runs under NDA before a part ships.
Which Fujitsu families we handle, and how hard each one is
Here’s a realistic map. “Usually feasible” means we’ve done comparable parts and expect a workable path; it is not a guarantee for your specific die.
| Family | Typical parts | Protection style | Feasibility |
|---|---|---|---|
| F2MC-8L | MB89xxx, MB95Fxxx | Simple flash protect bit / security byte | Usually feasible |
| F2MC-16LX | MB90F standard flash parts | Security bit blocking serial and parallel read | Usually feasible, part-dependent |
| F2MC-16FX | MB96Fxxx | Password / boot-ROM gated access | Case by case |
| FR family | MB91Fxxx | Security vector plus flash lock | Harder, evaluation first |
| FM3 / FM4 (Cortex-M) | MB9Bxxx, S6E2xxx | ARM debug lockout, flash security | Depends on lock state; often no |
| OTP and mask-ROM variants | MB89 OTP, custom ROM codes | No electrical read path at all | Silicon-level work only |
The pattern is the same one you see across older MCU lines generally: 8-bit parts from the 1990s and early 2000s have a single security bit protecting a flash array that was never designed against a determined attacker, while anything with an ARM core and a proper debug authentication scheme is a different problem entirely. It’s the same jump you get between an 8051 lock bit and STM32 RDP Level 2.
The MB90F series deserves its own note
MB90F387, MB90F462, MB90F543, MB90F349 — these show up constantly in automotive and industrial modules, and they’re the single most common request in our Fujitsu queue. The 16LX security bit disables the serial programming interface and the parallel read path, but it doesn’t encrypt the array. Approach depends on the mask revision printed on the package, which is why we ask for a photo of the marking rather than just the part number.
What makes an FM3/FM4 job different
Those are Cortex-M3/M4 devices with real debug port protection. If the customer set flash security and killed SWD, the non-invasive routes mostly close and you’re into decap and silicon-level analysis, which changes both cost and timeline substantially. We’ll say no to some of these rather than take money for a fishing expedition.
What actually happens to your chip in the lab
Nothing exotic in the first hour. The order matters more than the tools.
- Identify the exact die. Full top marking, date code, package, and any revision suffix. Two parts with the same base number and different mask revisions can behave differently on the programming interface.
- Confirm the part is alive. Power it on a test fixture, check the oscillator, check that it responds — or doesn’t — on the serial programming pins. A dead die is a repair problem, not an unlock problem, and we find this out before you pay for anything else.
- Read the protection state. Determine whether the security bit is actually set, whether the boot loader responds, and what the interface reports. A surprising number of “locked” Fujitsu parts turn out to be readable with the correct legacy tool and voltage sequence.
- Choose the route. Non-invasive interface work first. Semi-invasive or decapsulation only if the electrical route is closed and the customer approves the risk to the sample.
- Extract and verify. This is the step that separates a real dump from noise.
Verification is the part most vendors skip describing. For a Fujitsu MCU we check the reset vector points somewhere sensible, that the interrupt vector table at the top of the address space is populated the way the F2MC architecture expects, that flash-blank regions read as erased rather than as garbage, and — where the customer supplies a working board — that a freshly programmed part runs the machine. Two independent reads that match byte for byte is the minimum bar. A single dump with no cross-check is not a deliverable.
What to send us, and what you get back
Keep it short. We need enough to judge feasibility, not a full design package.
- A clear, in-focus photo of the chip’s top marking — all lines of text, straight on, good light. This matters more than everything else combined.
- Photos of both sides of the board on a dark background, whole board in frame, plus board dimensions if you want the copy work quoted too.
- Whether the part is still soldered to the board, and whether you can supply loose samples. Two or three identical parts materially improves the odds, because a semi-invasive route consumes samples.
- Whether the board still functions. A running unit is the best verification reference you can give us.
- One line on what you need: a raw binary/hex dump, blank parts programmed and returned, or a full firmware plus board package.
Back from us: a plain feasibility verdict (yes, no, or evaluation required), the route we’d use, an estimated lead time, and a price. If we think the answer is no, you get that in a sentence instead of a maybe. Deliverables are usually a verified binary or hex, an address-map note explaining what lives where, and optionally programmed replacement devices.
The limits — read this part before you order
Honest constraints, because the cases below are where projects go wrong:
- Mask-ROM and OTP parts. Some MB89 devices were shipped as customer-specific mask ROM. There is no electrical read path. Recovery means silicon-level imaging, which is slow, expensive, and only worth it for high-value legacy products.
- Data-flash and external EEPROM. Calibration constants, serial numbers and learned values often live outside the MCU. A perfect code dump plus a blank EEPROM gives you a module that boots and then refuses to work. Tell us if there’s a 93Cxx or 24Cxx nearby.
- Encrypted or checksum-bound firmware. If the original developer added a signature check tied to a unique ID, cloning to a new part needs extra analysis work beyond the read.
- Physically damaged dies. Water ingress, overvoltage events and cracked packages can destroy the flash array. We can sometimes still read a partially damaged array, but not always, and not predictably.
- Late FM4 parts with security fully enabled. Often not feasible at sane cost. We’d rather tell you that than bill an evaluation you can’t use.
- Single-sample jobs on invasive routes. If you only have one chip and it’s the last one in existence, we’ll usually recommend a non-invasive attempt only, and stop there.
When unlocking isn’t the right answer
Sometimes the cheaper path is a rewrite. If the firmware is a few kilobytes of straightforward I/O logic and you have the original functional spec, recreating it on a current MCU may cost less than a Fujitsu decap job — and it leaves you with maintainable source instead of a binary blob.
The reverse is true for anything with tuned control loops, motor commutation timing, or years of accumulated field fixes. Nobody reconstructs that from a spec sheet. Extract it, keep the behavior, then port deliberately if you need to.
Obsolescence work often pairs Fujitsu firmware recovery with a board-level effort, since a discontinued MCU eventually needs a new layout. We handle the same evaluation pattern for other legacy Japanese lines including Mitsubishi MCU unlock work, and for the older 68HC-derived families under Motorola and 68HC-series parts. If your board also carries a locked CPLD, that’s usually a separate evaluation — see Lattice programmable logic recovery for how those differ.
FAQ
Can you unlock an MB90F462?
Usually, yes — MB90F462 and its 16LX siblings are among the more approachable Fujitsu parts, and we’ve handled comparable devices. The variable is mask revision, so we confirm against the actual top marking before quoting. Send a photo of the chip and we’ll give you a straight yes, no, or “evaluation needed” answer rather than a generic maybe.
How long does a Fujitsu IC unlock take?
A cooperative 8-bit or 16LX part on a known route is typically a mat
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