Sixty-four kilobytes of flash, sixteen kilobytes of SRAM, a ten-bit converter with eight inputs and a single ten-bit analog output, all in the 64-pin package the whole LPC213x line shares. The LPC2132FBD64 is the middle of that family and by far the most common of them, because it was the point where the price of an ARM7 crossed what a 16-bit design used to cost.

Duplicating the program from one of these is routine work with an unusual complication: the same package, the same pinout and the same family name hide four different memory sizes, and the analog output that exists here is missing on the part one step below.

Sixty-four kilobytes, and where the boundary sits

The array is large enough that the program usually has structure: a resident section, a communication stack, and a parameter area that survives power cycles. That structure is what a duplicate has to preserve. An image copied byte for byte will run, but if the parameter sector is not identified, the first field update on the copy will write into code.

The top of the map is reserved for the bootloader, so the usable figure is slightly below the headline. On a rebuild this matters at link time rather than at run time, and it is the single most common reason a recovered image verifies and then fails to boot on a fresh device. A linker script copied from a larger member of the family will place the last section over the boundary and produce exactly that failure.

What the protection actually prevents

The word at 0x0000_01FC is read at reset. With read protection active, the debug port is closed and the ISP handler refuses Read Memory, Write to RAM, Go and Copy RAM to Flash, while still allowing an erase of all user sectors. Nothing is encrypted: the array is plain flash, served to the core normally, and the restriction applies to everything outside the core.

That is why the level in force decides everything. If a jump into RAM is still accepted, a small loader can be placed and run, and it reads the array from inside the boundary without the package being touched. If it is not, the work moves to the die, and the ECC bytes beside each sixteen-byte group have to come out with the data.

Duplication sequence

1. Confirm the type from the die: LPC2131, 2132, 2134 and 2136 share the package and differ in array size and in whether an analog output exists.
2. Record the boot dialogue and the debug port response to establish the protection level without writing to the part.
3. Recover the array by the route the level permits, in blocks that follow the physical sector boundaries.
4. Rebuild the vector table, restore the checksum at 0x0000_0014, and prove the image on a device of the same type.
5. Identify the parameter sector and document it, so that a later partial restore does not overwrite live calibration.
6. Compare the copy against the original on the bench: converter readings, analog output, serial timing and interrupt latency.

The delivered set

A HEX file, a binary, a sector map with the parameter area marked, and a short note on the analog configuration found in the code. Where the program derives its output from a table rather than from a calculation, the table is called out, since it is the part most likely to differ between two production batches. Method detail is on the microcontroller unlock service page and the package work under IC decapsulation service.

Before shipping

Include a photograph of the marking, the crystal value, and a note on what the analog output drives. If the board is still working, say so, because a live capture of the converter readings makes verification of the copy much faster. The part below is described for LPC2131FBD64, the two next steps up for LPC2134FBD64, and the USB-equipped equivalent for LPC2142FBD64.

Authorisation

Duplication is carried out on hardware the customer owns or is responsible for maintaining, confirmed in writing before work starts. The copy exists to keep installed equipment running and to provide spares, not to create a competing product. Requests that cannot show that standing are refused, and the reason is recorded with the job so there is no ambiguity later. Scope and terms are on the MCU crack service page.