There is a class of job where the technical work succeeds completely and the customer is still unhappy, and this part is the standard example. The protection can be removed. The device will accept code again and run it. What it will not do is hand back the firmware it was guarding, because removing the guard and destroying the contents are the same operation.

That is not an accident of implementation. It is the design, and understanding it before the unit goes on the bench is the difference between a job that finishes in an afternoon and a relationship that ends in a dispute.

The mechanism has no bypass

The protection word lives in the last four bytes of sector 0, alongside the vector table. Two paths can reach it: the debug port, if it is open, and the boot loader, if it is willing. Once a protection value is present, both paths are constrained in the same way — the only write that is permitted to that word is one that arrives as part of an erase of sector 0.

The erase is exclusive. The loader cannot erase sector 0 and leave the others alone, because it was never given that option. When the request arrives, the controller erases the whole array, the protection word goes with it, and the part is left blank and open.

The table is the whole argument. Every row that clears the protection also clears the content, and the only row that preserves content does not involve the protection word at all.

So what a completed break actually returns

A blank, open, working LPC2104. That is a real deliverable more often than it sounds. Boards that are bricked by a failed field update, units where the production line lost the image, and second-source situations where the customer owns the source and simply needs the part to accept a build again — all of these are solved by an erase, and none of them need the original content.

The problem is when the request was written as break the chip, meaning recover the heximal, and the two intentions were never separated. A working blank chip does not satisfy the second one, and no amount of further work at the port will close the gap.

It is worth asking the question early, in plain language: do you need the program, or do you need the part to run again. On a protected LPC2104 those are different jobs with different costs, and only one of them is available without opening the package.

What remains observable after the erase

Erasing does not erase knowledge of the product. Before the array goes, several things can still be collected, and each has value:

• The part identifier and loader version, read through the harmless commands, which pin down density and die revision for any future build.
• The board’s memory topology: external serial memory content, any configuration device, the crystal, the reset supervisor, the pin assignments implied by the copper.
• The behaviour of the running product, recorded from a known-good unit rather than the one about to be erased.
• The protocol on every port, captured while the device still speaks it.

None of this is the firmware, and all of it is frequently enough to rebuild or replace the product. A recovery report that contains these four items is more useful to an engineering team than a raw binary without context.

The one route that does preserve content

Where the customer genuinely needs the array and the part is in CRP2 or CRP3, the only remaining path goes through the package. Decapsulation, removal of the mould compound over the array, and a read of the flash cells or of the bus between the core and the memory controller. It is slow, it is destructive to the sample, and it requires the die to be powered and clocked while being probed.

That route recovers content because it does not ask the protection logic for permission. It reads the storage directly, and the storage is plain. The word that blocked the port has no meaning to a probe sitting on the bit lines.

Whether that is worth doing depends entirely on the value of the code, and it should be quoted as a separate exercise with its own failure modes rather than bundled into an unlock.

The sequencing that protects both sides

Collect, then measure, then decide, then erase. In that order:

1. Capture everything observable, including a working reference unit if one exists.
2. Determine the protection state from the shape of the refusal, not from a guess.
3. Put the two options in front of the customer in writing: a blank running part, or an invasive attempt at the array.
4. Only then send the erase.

Doing step four early is the single most common way a recoverable situation becomes an unrecoverable one, because a device that has been erased cannot be re-examined to establish what state it was in.

Related mechanics

The control word that drives all of this, and the three values that select the states, are covered in LPC2101FBD48 protection states. The behaviour of the checksum word that a rebuilt image must carry is in LPC2103FBD48 heximal work. And when the part is large enough that a single erased sector does not condemn the whole image, the arithmetic changes — see LPC2132FBD64 data recovery, where partial loss is survivable.

Closing note

Protection on this family is a lock with no keyhole: the only way through is to destroy the door. A supplier who promises to break the chip and return the heximal without saying which of those two things will actually happen is describing a procedure that does not exist. The honest version is shorter, cheaper, and considerably more useful to the person paying for it.

Comments are closed.