Prevent Duplicate Serial Numbers Across Programming Stations

Serial number problems often appear after a retry, station replacement or simultaneous production run. Incrementing a number in a local text file may work on one bench, but it does not define ownership when two stations operate or when a write succeeds just before the station loses its connection to the database.

Separate the identifier from the attempt

Define a unique product identifier and a separate programming attempt identifier. A physical board can have several attempts while retaining one approved serial number. Store the relationship explicitly. Otherwise a retry can create a second product record, or a later success can overwrite the evidence of an earlier failed operation.

Use clear states such as reserved, written, verified, released and quarantined. These are process states rather than recommendations for a particular database implementation. Decide which state makes a number unavailable for another board. A missing confirmation should not automatically mean that the number is safe to recycle.

Choose an allocation authority

For connected stations, use an allocation service or database operation that prevents two stations from claiming the same identifier. For offline stations, issue nonoverlapping controlled ranges and track which range belongs to each station. Document how unused numbers are reconciled when a station is retired.

SEGGER’s Flasher documentation describes serial number configuration and separate serial number data files for supported programmers. Check the behavior of the selected programmer and software version; do not assume copying a project also transfers, preserves or safely resets its serial number state.

Design the interrupted-write case

Consider an example: the station reserves number 10427, writes it, and then loses power before reporting verification. On restart, the system must determine whether the same physical board still occupies the fixture. Reading the stored identifier can help, where the device permits it. Blindly assigning 10427 to another board creates a duplication risk.

Define a recovery path that retains the original reservation and requires investigation when board identity is uncertain. If an identifier is retired, record why rather than silently returning it to the available pool. Gaps in a sequence are often easier to explain than duplicate identities.

Test the production workflow

Run two stations concurrently and deliberately interrupt communication at each state transition. Test rework, failed verification, board removal before completion and restoration of a station backup. Confirm that the printed label, stored electronic identifier and product record agree.

Keep credentials and private provisioning material out of ordinary operator logs. The traceability record needs enough information to identify the approved operation without exposing secrets. Review allocation behavior whenever station cloning, software updates or production expansion changes how identifiers are issued.