Two hundred and fifty-six kilobytes of flash and thirty-two kilobytes of SRAM, with two ten-bit converters, a ten-bit analog output and 47 pins of I/O in the same 64-pin body as the rest of the family. The LPC2136FBD64 is the point where the LPC213x line has enough memory to hold a real application and enough SRAM to work on it at runtime.

That combination changes what recovery looks like. On the smaller members of the family the program is compact and every byte is accounted for. Here there is usually a resident kernel, a communication layer, a menu system and a parameter store, and the job is to bring all of them back in a form that still fits together.

Thirty-two kilobytes of working space

A full sector can be held in SRAM several times over, which makes verification straightforward: read a block, read it again by a different path, compare in memory, and transmit only what survives. On a device with two kilobytes of RAM that sequence is impossible and every block is a one-off. Here a failed comparison simply means another attempt.

The same space makes it practical to run a reader entirely from SRAM when the protection level still allows execution there. The reader does not need to be small, so it can carry a proper transport, a block checksum and a retry counter, which is what turns an awkward job into a predictable one.

Where the setting lives

The bootloader reads the word at 0x0000_01FC on every reset. With read protection active, the debug interface is closed and the ISP handler declines Read Memory, Write to RAM, Go and Copy RAM to Flash, leaving only an erase of all user sectors. The protection is applied by software at the boundary; the flash controller itself serves the core without restriction.

The array is also large enough that a partial read is worth planning for. Twenty-two sectors of user flash cannot be held in SRAM at once, so the reader works in passes and keeps a running map of which blocks were confirmed and which need a second attempt. On a smaller part that bookkeeping is overhead; here it is what keeps a long job from ending in an unverifiable file.

Since the accepted operation under protection is a full erase, no procedure on this part may involve an erase at all. The moment one is issued the program is gone, and with 256 kilobytes there is no partial copy to fall back on. Every step before that point is therefore diagnostic, and it is done with the array untouched.

Unlocking an LPC2136FBD64

1. Establish the exact type and revision from the die and the marking, because the family shares a package across four memory sizes.
2. Capture the boot dialogue to identify the protection level from refusals rather than from documentation.
3. Use the SRAM route where it is open, with a reader that buffers whole sectors and verifies each twice before sending.
4. Where it is closed, decapsulate and read the array with the correction bytes for each sixteen-byte group kept in step.
5. Rebuild the vector table, restore the checksum at 0x0000_0014, and place sections within the original sector boundaries.
6. Identify the parameter sectors and mark them, so a later restore does not overwrite live calibration with factory defaults.

The program file that comes back

A HEX file with an address map, a binary, and a note on which sectors held code, which held parameters, and which were blank. The parameter area is documented separately because on a device this size it is normal for the last sector to hold values written during production rather than part of the program. Method details are on the microcontroller unlock service page and the physical access is described under chip reverse engineering service.

Before shipping

Include the crystal value, the state of the board, and whether the unit still runs its normal cycle. If the application writes to flash at runtime, say so, because that changes which sectors matter and how the copy has to be handled. The part below is covered for LPC2134FBD64, the largest of the family for LPC2138FBD64, and the USB-equipped equivalent under LPC2148FBD64.

Authorisation

Work is carried out on hardware the customer owns or is contracted to maintain, with that standing confirmed in writing first. The recovered program is returned for repair and continued support of existing units. It is not supplied for the manufacture of a competing product, and requests that would require that are refused with the reason recorded. The overall process is on the firmware extraction service page.