The LPC2106FHN48 is the same silicon as the LPC2106FBD48 in a different body: an HVQFN48, 7 by 7 millimetres and 0.85 millimetres thick, with no leads at all and a large exposed pad underneath for thermal and ground connection. Everything inside is identical, 128 kilobytes of flash, 64 kilobytes of SRAM, 60 MHz ARM7TDMI-S. Everything about getting at it is not.

No-lead packages are chosen for size and for heat, and they are used on boards where the space around the device is tight. Both of those choices make a recovery job harder before any electrical work starts.

What the package changes

A leaded LQFP can be probed from the side, and individual pins can be lifted or bypassed when a board has to keep running during measurement. An HVQFN exposes only the terminal lands on the underside, which sit under the part and are covered by solder once assembled. There is no side access, the pitch is fine, and the thermal pad is bonded to the ground plane across its whole area.

Removing one without damaging the board takes preheat from below and controlled hot air from above, and the pad makes the thermal mass deceptive: the part comes loose later than the solder around it suggests. On a board with a ground plane this size, a cold pull takes pads with it.

The thermal pad is also where most of the heat leaves the device, which is why boards built around this package often have a via array underneath. That array is useful later: it gives a low-impedance path to the ground plane and a stable reference for probing, and it tells you how much copper is waiting to pull heat away when the part is reflowed.

The electrical route before the physical one

Everything reachable through the bootloader is tried first, because it costs nothing and leaves the device untouched. The protection word at 0x0000_01FC determines what the bootloader will agree to. Under the least restrictive settings the serial port still accepts writes and jumps, and a loader placed in RAM can read the array from inside the boundary.

With the strict setting, the ISP handler refuses Read Memory, Write to RAM, Go and Copy RAM to Flash, and the debug port is shut, so the only remaining operation is a full erase that would destroy the very thing being recovered. Identification of which state the device is in is done from its responses alone, before anything is written.

Unlocking an LPC2106FHN48

1. Photograph the board and the part marking, and note any rework around the device, since a previously reflowed HVQFN behaves differently under heat.
2. Capture the reset sequence and the bootloader dialogue to fix the protection level and the boot path.
3. If RAM execution is open, deliver a loader over the serial port, run it, and pull the flash out in eight-kilobyte sectors.
4. If it is closed, plan the removal: preheat, controlled reflow, and a fixture that supports the board while the part is lifted.
5. Decapsulate and locate the array and its ECC region, then read with the correction bytes retained per sixteen-byte group.
6. Rebuild the vector table, restore the checksum at 0x0000_0014, and validate the image on a leaded equivalent before it is used.

Deliverables

A HEX file, a binary, an address map that records which sectors were in use, and a note on the package type and the condition found underneath it. If the part had to be removed, the report says whether the pads survived, because that decides whether the board can be returned to service with a replacement device. The package side of the work is described under IC decapsulation service, and the diagnostic sequence under chip reverse engineering service.

Before sending the board

Include the crystal value, the supply arrangement, and whether the device still runs. Boards that are still alive are preferred, since the boot dialogue can then be recorded rather than reconstructed. The leaded version of the same part is covered for LPC2106FBD48, the smaller array for LPC2104FBD48, and the wider supply detail sits on the firmware extraction service page.

Authorisation

Work is accepted only on equipment the customer owns or is formally responsible for maintaining, and that is confirmed in writing before the package is opened. The purpose is repair and legacy support of existing hardware. Requests that amount to copying another company’s product are refused, and the reason is stated plainly so the position is never ambiguous.