Four CAN controllers in a single 64-pin microcontroller, with 256 kilobytes of flash and sixteen kilobytes of SRAM. The LPC2194HBD64 is the only member of the LPC2000 family with four buses on one die, which is why it appears in gateways, protocol bridges and machines that had to join several networks without adding hardware.

Decoding the program on one of these is different from working on a single-bus node. A gateway holds several pieces of logic that each look like a small application, and the value of the recovered image depends on being able to say which part of it belongs to which network.

Four buses, four behaviours

Each controller has its own bit timing, its own acceptance filters and its own error counters, and the four are configured independently. That independence is visible in the program as four initialisation blocks that differ only in their parameters, which makes the code easy to partition once the parameter tables are located.

It also gives an unusually good external check. A gateway that routes between segments announces its routing rules through the identifiers it forwards and the ones it drops. Capture the traffic on each side and the recovered image can be matched against observed behaviour port by port, which is a far stronger validation than a checksum.

Four controllers also mean four interrupt sources sharing one vectored interrupt controller, and gateways built on this part usually prioritise them by traffic criticality rather than by arrival order. The priority registers are written once at start-up and rarely touched again, so the values found there describe the integrator’s judgement about which segment could tolerate delay. Recovering that judgement is often more valuable than recovering the arithmetic, because it explains behaviour that otherwise looks arbitrary when a segment goes quiet.

The protection word and the erase trap

At 0x0000_01FC the bootloader finds the setting it applies. Read protection closes the debug port and makes the ISP handler refuse Read Memory, Write to RAM, Go and Copy RAM to Flash; the only erase permitted is across all user sectors. On a quarter of a megabyte that is a single command that ends the job, so it is never issued.

Recovery therefore runs either from code executing inside the device, where the level still allows a jump into SRAM, or from a physical read after the package is opened. Which of the two applies is established from the reset behaviour, and the level is never inferred from the part number or from documentation.

Decoding an LPC2194HBD64

1. Capture traffic on every bus the device is connected to, with identifiers and timing, before anything is opened.
2. Establish the protection level from the boot dialogue and the debug port response, with the flash untouched.
3. Recover the array by the route the level allows, in sector-aligned blocks with per-block verification.
4. Rebuild the vector table and the checksum at 0x0000_0014, and prove the image on a substitute device.
5. Partition the recovered code by bus: bit timing, filters, routing tables and error handling for each controller.
6. Match the partitions against the captured traffic, so the routing description is derived rather than assumed.

What the decode produces

A HEX file, a binary, a sector map, and a written description of the gateway behaviour: what each controller is configured for, which identifiers are forwarded, and how the device responds to a bus-off condition. For this part that description is the deliverable that gets used, because a replacement gateway has to behave identically on four networks at once. Method notes are on the MCU crack service page and the package approach under chip reverse engineering service.

Shipment notes

Send the board with all bus connections labeled, the crystal value, and a note on whether the gateway still routes. A live unit is worth far more here than on a single-bus device, because the routing behaviour can only be observed while all four segments are active. The two-bus parts are covered for LPC2129FBD64, and the 144-pin four-bus device under LPC2294HBD144.

Authorisation

Decoding is performed on equipment the customer owns or maintains under contract, confirmed in writing before the package is opened. The results support repair, spares and documentation of installed machinery. They are not used to build a competing product, and requests that would require that are declined with an explanation. The broader service is described on the firmware extraction service page.