A duplicate that runs is not the same thing as a duplicate that behaves. The difference is almost always the clock, and on this family the clock is a small block of registers set by the first fifty instructions of the firmware.

Copying flash is a solved problem once the array is readable. Reproducing the timing environment the flash expects is the part that determines whether the resulting board meets its specification or merely boots.

What the clock chain looks like

The device can run from an external crystal through a phase-locked loop, or directly from the crystal, or from an internal oscillator depending on the variant. The interesting case is the loop, because that is what production firmware uses.

The loop multiplies the oscillator up to an internal frequency and divides it back down to the core clock. The multiplier and divider are set as two fields in one register: a multiplier, and a divider restricted to a small set of powers of two. The settings are then committed with a fixed two-byte sequence written to a feed register, because an accidental write to a clock register is a good way to stop a device permanently.

Below the core clock sits a second divider that sets the peripheral bus. On this family it can be the core clock, half of it, or a quarter. Every peripheral timing reference — baud rate, timer tick, CAN bit, ADC conversion — is computed against that bus clock, not against the core.

Why a byte copy fails on a different board

Three failure modes account for almost every case.

The first is a different crystal. A board built with a 12 MHz part and a board built with a 14.7456 MHz part produce different core clocks from the same register values, and every derived timing shifts by the same ratio. The UART baud rate lands on a value the other end does not recognise; the product appears dead on its service port.

The second is the same crystal with a different loop setting. This happens when a product was cost-reduced: the firmware was rebuilt for a slower core to save power, and a copy of the older image runs the new board too fast, which shows up as marginal flash access rather than as an obvious fault.

The third is the peripheral divider. Changing it changes all peripherals at once, which is why a board that boots and communicates but cannot measure accurately is nearly always a divider mismatch rather than an analog problem.

Reading the configuration out of the image

The clock setup is the first thing the reset code does, before memory is initialised and before any peripheral is touched, which makes it easy to find. Look for writes to the clock block near the base of the array, immediately after the stack pointer is set.

Extract the multiplier and divider, compute the resulting core frequency against the crystal the board actually has, and compare it against the frequency the rest of the firmware assumes. The rest of the firmware states its assumption implicitly, in the constants loaded into baud rate divisors and timer reload registers, so the two can be checked against each other.

When they agree, the image was built for this board and the duplicate will behave. When they disagree, the image came from a different board revision, and that is a finding worth reporting before anything is written to a replacement.

Reworking instead of matching

Sometimes the crystal on the new board cannot be changed. In that case the image has to be reworked, and the work is mechanical but wide: recompute every baud divisor, every timer reload, every CAN bit timing, every delay loop.

Software delays are the ones that bite. A loop written as a fixed count of iterations has its timing baked into the instruction stream, and no register adjustment fixes it. Products with bit-banged protocols or charge-pump sequencing often contain such loops, and a duplicate that runs ten percent fast can fail in ways that look mechanical.

Protected devices change the order of work

Where the device is protected, the configuration cannot be read out through a port, and the sequence becomes: establish access first, then read, then analyse the clock, then decide. The access question is covered in LPC2101FBD48 protection states, and the read itself in LPC2102FBD48 data recovery.

What must not happen is a duplicate produced from a partial understanding: image copied, clock assumed, board shipped. The failure appears weeks later as an intermittent fault in the field, and by then the connection between cause and effect is lost.

Deliverable

A duplication job should hand over four things: the image, the clock configuration as extracted, the derived frequencies for the board the image came from, and a statement of what must match on the replacement board. That fourth item is the one that prevents the second job, and it costs a paragraph.

The wider reading of what else travels with an image — interrupt structure, parameter blocks, network identity — is in LPC2134FBD64 firmware extraction and LPC2129FBD64 firmware recovery. Where the product also introduces itself on a bus, as the USB variant does in LPC2141FBD64 heximal replication, that identity has to be matched as carefully as the clock. For the arithmetic of a partial image, LPC2132FBD64 data recovery covers what to do when part of the array is missing.

The short version

Copy the flash. Then prove the clock. A duplicate that has been checked against its timing assumptions is a product. A duplicate that has only been verified byte for byte is a hope.

Comments are closed.