Clone NXP Microprocessor LPC2146FBD64 Flash Program

Two hundred and fifty-six kilobytes of flash, thirty-two kilobytes of SRAM plus eight kilobytes that the USB DMA controller can borrow, two ten-bit converters across fourteen inputs, a ten-bit output and USB 2.0 full-speed, in a 64-pin LQFP. The LPC2146FBD64 is where the USB family stops being small: the extra RAM pool is the detail that separates it from the parts below.

Because that eight kilobyte block can be used as ordinary SRAM when the DMA engine is idle, firmware on this part often does something the smaller members cannot: it keeps a working buffer, a queue, or a resident routine in memory that would otherwise have to live in flash. For anyone cloning the design, that is both an opportunity and a trap.

The borrowed eight kilobytes

The block is described as USB DMA RAM because that is what it was added for, but it is addressable by the core. A program can place data there, and a programmer can place code there, provided nothing reconfigures the DMA controller to take it back. Recovery routines written for this device exploit exactly that: a reader can sit in the borrowed block, use the main SRAM for buffers, and leave the flash completely alone.

The trap is the reverse case. Firmware that used the block for a queue will behave differently on a device where the DMA engine has claimed it, and a copy that runs on the bench can fail in the field when USB traffic starts. Any recovered image has to be read with that sharing rule in mind.

There is a second reason the block matters during recovery. A reader placed there does not compete with the USB stack for main SRAM, so a device can stay enumerated while its flash is being read, which is exactly what a live capture needs. On the parts without the extra block the same trick forces the USB stack out of memory, and the host sees a device disappear mid-transfer.

Protection on the LPC2146

The word at 0x0000_01FC sets the level at reset. Read protection closes the debug port and makes the ISP handler refuse Read Memory, Write to RAM, Go and Copy RAM to Flash, leaving an erase of all user sectors as the only accepted operation. The array is plain flash, served to the core without encryption, so the boundary is external only.

Identification comes before action. The bootloader’s refusals, the state of the debug port, and the acceptance or rejection of a jump into RAM together fix the level precisely. On a part with this much memory the identification matters more than usual, because a mistaken erase costs a quarter of a megabyte.

Cloning sequence

  1. Confirm the type and revision from the die: the package is shared across five memory sizes and the RAM split differs between them.
  2. Record the reset dialogue and the ISP responses to establish the protection level with the flash untouched.
  3. Recover the array by the route the level allows, reading in sector-aligned blocks and verifying each twice.
  4. Rebuild the vector table, restore the checksum at 0x0000_0014, and place sections within the original boundaries.
  5. Map the use of the borrowed RAM block: which regions hold data, which hold code, and what reconfigures the DMA engine.
  6. Prove the copy with USB traffic running, since that is the condition under which the sharing rule actually applies.

What is delivered

A HEX file, a binary, an address map that marks code, parameters and blank areas, and a note on how the eight kilobyte block is used by the original firmware. That note is what allows a replacement board to be trusted in service rather than only on a bench. The method is described on the IC clone service page, and the package work under IC decapsulation service.

Shipment notes

Give the crystal, the USB connector wiring, and whether the unit still enumerates and runs its main function. A live unit lets the DMA behaviour be observed, which is the only reliable way to confirm how the borrowed block is shared. The part below is covered for LPC2144FBD64, the largest of the family for LPC2148FBD64, and the non-USB equivalent under LPC2136FBD64.

Authorisation

Cloning is performed on equipment the customer owns or is contracted to maintain, confirmed in writing before the package is opened. The result supports repair and spares for installed hardware. It is not supplied for reproducing another manufacturer’s product, and requests that would require that are declined with the reasoning stated. The wider scope is on the firmware extraction service page.