Sixty-four kilobytes of SRAM and no flash at all, in a 144-pin package with a full external memory bus. The LPC2220FBD144 is the memory-heavy member of NXP’s flashless LPC2200 group, built for systems that needed a large working memory more than they needed on-chip program storage.

Designs that used it did something that changes the recovery problem completely: they loaded the application into SRAM and ran it from there. There is no array to protect, no protection word to read, and no bootloader that could refuse a command. What exists is a running image in volatile memory, and the only moment it can be taken is while the board is alive.

A device whose firmware is volatile

On a flash-based part the program is a fixed object. Here the program arrives from somewhere else at start-up: a host processor over a serial or parallel link, a flash device on the external bus, or a boot ROM in a larger system. Once it is in SRAM it may be modified in place, relocated, or partially overwritten during operation.

That means the recovery is a capture rather than a read. The board is brought up under controlled conditions, allowed to complete its load, and the SRAM is taken while the application is running. If the load path is understood, the same capture can be repeated with different inputs to see which regions change.

Why decapsulation is still part of the job

Capturing the bus while the code is being loaded is the cleanest method, but it requires the load to happen on a bus that can be observed. On boards where the image arrives over a link that is encrypted, compressed, or simply too fast to capture with the equipment at hand, the alternative is to read the SRAM from the die after the load has completed and the device is held in a known state.

That is where opening the package earns its place. With the die accessible, the SRAM can be read directly, at a point chosen by the operator, without the CPU cooperating. The sixty-four kilobyte array is small enough that several passes are practical, and comparing them shows which regions are code and which are live data.

Working on an LPC2220FBD144

1. Inventory the external memory and the load path, and establish what the controller boots from.
2. Bring the board up under a controlled supply and capture the load sequence on every observable bus.
3. Record the state of the SRAM at several points: after load, after initialisation, and during normal operation.
4. Where the load cannot be observed, decapsulate and read the SRAM directly at a chosen moment.
5. Separate code from data by comparing passes, and label regions that change with input as data.
6. Reconstruct an image that can be reloaded through the same path, and prove it by running the board from it.

What a firmware image means here

For this device the deliverable is a memory image plus a description of the load path: where the code enters, which regions are initialised from the image and which are set up at runtime, and what has to be present on the board for the image to run. That description is what makes the capture reproducible. Where the image is compressed in transit, the decompressed form is supplied along with a note on how it was obtained. The method is on the IC decapsulation service page, and the analysis behind it under firmware extraction service.

Shipment notes

Send the whole board, not the controller alone, because the load path is the point. Include the crystal, the memory devices fitted, and a note on how the system starts. A board that still completes its load is essential for this part. Its flash-carrying sibling is covered for LPC2214FBD144, the other flashless device for LPC2210FBD144, and the two-bus version under LPC2290FBD144.

Authorisation

Work is carried out on equipment the customer owns or is contracted to maintain, confirmed in writing before the package is opened. The result supports repair, spares and analysis of installed systems. It is not supplied for reproducing another manufacturer’s product, and requests that would require that are declined with the reason given. Broader terms are on the MCU crack service page.