Retrying a Failed Flash Operation: Confirm the Same Unit and Artifact Before Repeating
After a programmer disconnects, revoke the previous connection’s permission to write. Re-establish the physical unit, selected adapter, approved artifact and programming recipe, then reconcile the interrupted operation before considering a retry. USB reconnection or a familiar filename is not enough evidence to repeat a flash command.
The concrete interface reference is upstream OpenOCD 0.12.0. An original Python 3.12.14 model exercised ten synthetic retry-admission cases without opening a device or invoking a programmer. Physical identity checks, interrupted-flash recovery and actual retries remain proposed target-specific qualification work.
Keep adapter identity separate from unit identity
The OpenOCD 0.12.0 adapter serial command selects an adapter by its serial string for the supported drivers listed in that release. If it is omitted, serial strings are not checked. Confirm that the deployed driver actually supports the selector rather than assuming every interface interprets it.
An adapter serial identifies the debug probe, not necessarily the device under test. The same probe can be moved to another board while retaining its serial. A USB topology path identifies a host attachment location, which also does not prove which product is connected to the probe’s target cable.
Bind the station’s scanned unit identity to a trusted product-side observation where the design supports one. A chip-family identifier is not a unique unit identifier, and a barcode read before an operator swaps the board is stale evidence. Document how an unprogrammed unit is identified when its final product serial does not yet exist.
Create an immutable attempt record
Before admitting the first write, retain the unit binding, adapter selection, fixture/nest, artifact digest, intended address map, programmer configuration and attempt identity. Include any per-unit inputs separately from the common image. A release filename can remain unchanged while its bytes are replaced.
Keep the approved artifact available as an immutable input to the attempt. Reopening a mutable download path during retry can substitute another image even if the user interface still displays the old release name. Digest comparison detects a changed input only if the actual bytes supplied to the programmer are the bytes whose digest was checked.
Give each physical connection instance a new generation or lease identity. Commands and completions must carry that identity. On disconnect or uncertain fixture occupancy, invalidate the lease and stop admitting new operations immediately; a late success message from the old instance cannot authorize work on the new one.
Treat interruption as an uncertain operation outcome
A host timeout or USB error does not prove that the target remained unchanged. The programmer may have completed some erases or writes before the response was lost. Record the last confirmed phase and preserve logs without guessing how much of the image is valid.
The tagged program helper includes an erase-capable write path and separate optional verification and reset actions. Repeating the helper is therefore a new potentially modifying operation, not merely a request to retrieve the missing response.
Use the target and flash driver’s documented recovery method to establish a known state. Required inspection may itself halt or reset the target, so review its consequences. Preserve calibration, identity and recovery data before any write-based repair. No generic mass-erase fallback is justified by a disconnected probe.
Use explicit states instead of an automatic retry loop
| Station state | Required evidence | Permitted next step |
|---|---|---|
| Connection lost or occupancy uncertain. | Old lease invalidated; in-flight outcome retained as uncertain. | Stop new writes and reconcile the old worker/tool. |
| New connection discovered. | New lease and explicit adapter selection. | Perform the approved identity/readiness checks. |
| Binding re-established. | Unit, artifact and recipe match the intended attempt. | Assess previous operation state and recovery requirements. |
| Retry eligible. | Reconciliation completed and bounded retry policy approves this case. | Start a newly identified attempt under the new lease. |
| Any mismatch or missing evidence. | Reason recorded without silently adopting the new value. | Hold for controlled reassignment or engineering disposition. |
A different adapter can be deliberately approved as a replacement, but that is a new binding decision. Do not make the retry predicate accept every newly discovered device simply to keep the line moving. Similarly, a changed artifact requires the corresponding controlled workflow rather than being disguised as the same retry.
Read the executed synthetic controls
The host model compared an expected tuple of adapter, unit, artifact and recipe with a supplied current tuple. It also required the current generation, a reconciled prior outcome and an approved retry condition. These fields were synthetic assumptions; the model did not authenticate hardware or decide whether a flash operation was safe.
All ten expected decisions passed. The unchanged binding under a new valid generation was eligible. A stale generation, another unit on the same probe, another probe, changed artifact, changed recipe, missing unit, missing artifact, unresolved prior outcome and absent retry approval were each held.
The same-probe/other-unit case is important: locking only the USB serial would have accepted the wrong board. The unresolved-outcome case is equally important: correct identity does not establish that repeating a partially completed operation is appropriate.
Qualify the physical races separately
On recoverable development hardware, test unplug/replug, probe re-enumeration, board replacement on the same probe and a delayed completion from an old worker. Include two compatible adapters attached simultaneously so accidental first-device selection is visible.
Exercise the transition between final identity confirmation and command admission. A software check can become stale before the tool acts. Fixture occupancy controls, exclusive ownership and serialization must preserve the binding across that interval; the pure predicate cannot supply physical interlocks.
After any approved retry, require the complete programming, verification and functional gates for that new attempt. Link it to the interrupted predecessor without overwriting the predecessor’s uncertain result. A later success does not tell you exactly what happened before the disconnect.
The release deliverable is an identity-bound retry state machine, a reviewed recovery policy and evidence that stale connections cannot act on replacement units. Its value is preventing an uncertain communication failure from becoming an unexamined second write to the wrong target.
