Duplicate NXP LPC2104FBD48 Microcontroller Memory Program

Step from the LPC2101 up to the LPC2104FBD48 and the geometry changes completely. The array is 128 kilobytes, organised in sixteen sectors of eight kilobytes, and the SRAM grows to sixteen kilobytes. The core still runs at 60 MHz, the package is still a 48-pin LQFP, and there is still no ADC, no CAN and no USB, so this is a pure computing part with a serial port and a lot of program space.

That combination put it into protocol converters, small gateways and industrial timers where the job was mostly state machine and table lookup. Duplicating such a board today usually means recovering the program from a device that has been locked since it left the factory.

Sixteen sectors, one boot block, and 400 milliseconds

With eight-kilobyte sectors the map runs from sector 0 at 0x0000_0000 to sector 15 at 0x0001_E000. A single sector erase on this part takes about 400 milliseconds, and that figure is worth keeping in mind because it sets the pace of every write cycle in the bootloader and in any tool built on it. Programming runs at 512 bytes per millisecond.

Unlike the small LPC2101, this device reserves space at the top of the map for the boot block, so the usable user area is slightly less than the headline figure. The difference matters when an image is being rebuilt and the linker has to be told where it may place the last sector.

How the protection is expressed

One word at 0x0000_01FC carries the setting. The bootloader reads it at reset and applies it before the application gets control. With the word set to the value that enables read protection, the JTAG port is closed and the ISP handler refuses Read Memory, Write to RAM, Go and Copy RAM to Flash, while still permitting an erase of all user sectors. A device in that state answers on the serial line, reports that the command is refused, and otherwise behaves normally, which is why a failed read is often mistaken for a dead chip.

Because the protection is evaluated by software in the bootloader rather than enforced by the flash controller, the state of the device is knowable. The responses on the serial port and the behaviour of the debug interface identify the level precisely, and that identification is done before anything is written.

Practical recovery on an LPC2104FBD48

  1. Read the top marking and establish the revision, then map the board: supply rails, crystal, reset supervisor, and which pin the bootloader samples.
  2. Capture the boot dialogue and record exactly which commands are answered and which return a protection error.
  3. If execution from RAM is still available, a loader of a few kilobytes can be placed and run, and the flash streamed out through the serial port in blocks with per-block checksums.
  4. If it is not, decapsulate and work at the array level, reading sector by sector and keeping the ECC bytes for each sixteen-byte group.
  5. Rebuild the vector table, recompute the checksum word at 0x0000_0014, and confirm the image runs on a substitute part.
  6. Record which sectors were programmed and which were blank, since blank areas in this map are meaningful to the application.

The file that is handed over

An Intel HEX file and a raw binary, an address map, and a short report on what was found. Where the program turns out to be a bootloader plus an application with a jump table between them, both are labeled so that a later engineer can tell which is which. The general workflow sits on the firmware extraction service page, and the die-level reading is covered under chip reverse engineering service.

Notes for the shipment

Say whether the device is still running, because a live board allows the serial capture to be taken under power rather than inferred. Include the crystal value and any external memory fitted. If the design has to be reproduced rather than repaired, the same work supports LPC2106FBD48, which shares the array size but doubles the SRAM, and LPC2102FBD48 for the smaller geometry.

Authorisation

The service is limited to hardware the customer owns or maintains under contract, confirmed before work begins. Recovered code is returned to that customer for repair and legacy support, and is not distributed or reused. Where that standing cannot be shown, the request is declined and the reason is given. Cloning as a service is described separately under IC clone service.