Copy is the word customers use for four different jobs, and the cost of the four differs by more than an order of magnitude. The confusion runs in both directions: a customer who wanted the bits and is quoted for a rebuilt project believes he is being overcharged, and a customer who wanted a rebuild and receives a binary believes he has bought something useless.

The four objects are the bits, the code, the behaviour, and the unit. Each has an acceptance test, and the test is the only honest definition of done.

Object What you receive Acceptance test
Bits A binary image Byte-identical to a known dump
Code A buildable project Recompiles to equivalent behaviour
Behaviour A specification Matches on a test vector set
Unit A working device Passes the product’s own test

Object one: the bits

The bit copy is the simplest and the one most people mean. It answers one question — what is in the array — and finishes when a second device behaves identically.

Its limit is arithmetic rather than technical: the image carries no information about what the bytes mean, so a copy of a device trimmed at final test carries the donor’s trim values, and the recipient measures slightly wrong with nothing in the file saying so.

The shape of an incomplete bit copy is worth knowing, because it recurs across families. The 14-bit PIC case shows a read that stops before the configuration word, and the PIC32 two-region read shows one that stops before the boot flash. Both files are the right length and both devices fail to start.

Object two: the code

A code delivery claims more. It says the image has been disassembled, annotated, and reassembled into a project that compiles.

Claim What it requires What it still lacks
Builds Toolchain and linker script The original code size
Equivalent Test vectors passed The original source
Maintainable Named functions, comments The designer’s intent

This is where most disappointment lives. A buildable project is achievable; one a firmware engineer would recognise as his own is not, because the compiler discarded that information. Recovered structure, not source, is the realistic deliverable.

Object three: the behaviour

Behavioural recovery is the right object when the source is lost and the device must be replaced rather than duplicated. It produces a specification and a fresh implementation.

The acceptance test is a vector set, and the honest caveat is that the set defines the scope. Behaviour that was never observed is not in the specification, and the divergence appears later, on the path nobody tested.

Object four: the unit

The fourth object is a working device, the only one the customer can hold. Everything above is an input to it.

The acceptance test is the product’s own production test. If the customer has one, the argument about fidelity is settled in an hour; if not, the four objects are the only vocabulary for describing what was bought.

Where the four break

Each object fails in a characteristic way, and knowing that in advance prevents promises that cannot be kept.

Failure Object Cause
Wrong trim values Bits Per-unit data carried across
Builds but misbehaves Code Interrupt timing changed
Untested path diverges Behaviour Scope of the vector set
Passes on the bench, fails in the field Unit Aging not represented

The first, third and fourth are statements about what is per-unit. A copy is a claim about a class; a unit is one member of it. The distinction is developed in three sources for rebuilding flash, and the class-and-member problem in cloning is in clone IC firmware.

The order of questions

The order is fixed, and it starts away from the bench. What will be done with the result? Duplicate a production run, repair one unit, understand a competitor’s design, or replace an obsolete controller.

Each answer selects one of the four objects, and the object selects the technique. Starting from the technique is how these projects go wrong: a customer who asks for a decapsulation because he read about it has skipped the question, and the honest answer is sometimes that the bits were readable through a port all along.

There is also a fifth answer that is not a copy: the device is still in production and a distributor has stock.

What we do

We name the object before quoting: a bit image, a project, a specification, or a unit, with the acceptance test written into the sentence.

The measurement behind that choice — which ports respond, what the array protection actually is, whether an image is even readable — is the work described in read MCU code. Moving an array between two devices is covered in copy IC code, and the case where the original image must be rebuilt from fragments rather than read is in recover MCU firmware.