No on-chip flash, sixty-four kilobytes of SRAM, two CAN controllers and a 144-pin package with four external banks. The LPC2290FBD144 is the flashless part for systems that had to sit on a bus, and it is a favourite in designs where the program was expected to change: a gateway whose routing table came from a host, or a controller whose application was loaded from a card at start-up.

Cracking one in the useful sense means recovering the running program and the two bus configurations that go with it. Neither lives in a non-volatile array, so the approach is different from every flash-based part in the family.

Two buses and no fixed program

The controllers are configured at start-up by whatever code the board loaded, so their bit timing and filter settings belong to the application rather than to the hardware. A unit captured at one site may be running a build with different timing from an identical unit at another, because the load source differed.

This is why two captures are usually taken. The first records the bus traffic and the controller configuration in normal operation. The second records the SRAM contents after the load, which is the program itself. Comparing the two shows which parts of the image are routing logic and which are the tables that drive it.

There is a second difference worth stating plainly. On a flash part, an operator who cannot read memory can at least erase and reprogram. Here there is nothing to erase, so a board that will not complete its load is not recoverable by programming at all. The team that built the system had to solve that problem too, usually with a recovery mode in the load path: a jumper, a special frame, or a second source selected by strapping. Finding and using that mode is often faster than any physical work, and it is tried first.

What replaces decapsulation as a first step

On a flash part the first question is what the protection word allows. Here there is no such word. The equivalent question is whether the load path can be observed, because that decides whether the job is a capture or a die-level read.

Where a host loads the image over a bus that can be monitored, the capture is straightforward and non-destructive, and the board can be returned to service afterwards. Where the image arrives in a form that cannot be observed, or where the board no longer completes its load, the SRAM is read directly from the die after decapsulation. Sixty-four kilobytes is small enough that this is a routine operation rather than a project.

Cracking sequence

1. Document the load path and every bus the device is connected to, including the two CAN segments.
2. Capture the load sequence and the controller configuration at start-up.
3. Record the SRAM image after load, and again during normal operation, to separate code from live data.
4. Decapsulate and read the SRAM directly where the load cannot be observed or the board will not start.
5. Reconstruct the application image and the two controller configurations, and relate them to the captured traffic.
6. Prove the reconstruction by returning the image through the same load path on an equivalent board.

What is delivered

A memory image, a description of the load path, and a written account of the two controller configurations including bit timing, filters and error handling. For a gateway that account is the part that gets used, because a replacement unit has to behave identically on both segments. Method notes are on the MCU crack service page, and the physical work under firmware extraction service.

Before sending a board

Send the complete board with both bus connections labeled, the crystal, and a note on how the system is started and from where. A unit that still loads and runs is required for a capture; without that, the job becomes a die-level read and the load path has to be inferred. The single-bus flashless part is covered for LPC2220FBD144, the flash-carrying four-bus device for LPC2294HBD144, and the four-bus 64-pin part under LPC2194HBD64.

Authorisation

Work is accepted on equipment the customer owns or is contracted to maintain, confirmed in writing before the package is opened. The results are for repair, spares and documentation of systems already installed. They are not used to build a competing product, and requests that would require that are refused with the reasoning recorded.