5

I'm brand new to electronics and was wondering if someone could explain to me how individual MCU/MPU-powered electronics units can be assigned unique identities on the factory line.

For instance, lets say a particular device is being built. This device has an MCU/MPU (still don't fully understand their difference) that has a CPU, ROM to hold a binary/RTOS and RAM for running that binary at runtime. A control program is flashed to the ROM at some point during production.

Say this device has the need to be given a UUID that can be read from memory when the control program starts up. Obviously, each device needs a different (unique) ID. And so I would imagine that the MCU would undergo two different phases during its production build: an initial flashing of the control program to ROM, followed by a second flashing that "appends" (without overwriting, that is) a device-specific UUID to a specific address in ROM. The control program would then be hardcoded to look for the value (UUID) stored at this address at startup.

Am I on track here, or is there a more efficient/different/standard way of accomplishing such a task? And I guess I would generalize it beyond a UUID and ask the same question of any situation where all units share a binary (the control program) but then also have their own unique information that must be present in ROM at startup.

smeeb
  • 787
  • 3
  • 13
  • 32
  • Nit-pick - it's not ROM (Read-Only Memory), it's flash or EEPROM. ROM is part of the masks used in creating the die and **cannot** be written to, at all! – DoxyLover Aug 25 '15 at 17:08
  • @DoxyLover: You wouldn't want to use flash or EEPROM for this -- those are erasable (the second E in EEPROM is Erasable). Better to use a One-Time-Programmable memory. – Ben Voigt Aug 25 '15 at 18:20
  • 1
    @BenVoigt - never the less, OTP is **not** ROM. My point is you cannot use "ROM". – DoxyLover Aug 25 '15 at 18:32
  • 1
    Depending on how critical uniqueness is, there might be a problem if the computer storing your programmer and the identifiers has to be restored from backup: you can lose track of your identifier (http://programmers.stackexchange.com/questions/234795/how-can-one-guarantee-unique-identifiers-even-in-the-case-of-system-collapse-an) Of course, if you have access to a good random number generator and if your identifier can be large enough, it's not a problem: the probability of a duplicate will be lower than winning every lottery in every country on the whole planet... – vsz Aug 26 '15 at 04:33

5 Answers5

7

Production programmers generally have an option to serialize the image written to the memory: each individual product is flashed with data that is different, for instance by incrementing a specific data word, but more complex operations are also possible.

Another option is to buy a chip that itself has a unqiue number. This is for instance done for Ethernet addresses, which are assigned by some authority. Check for instance Microchip's "Unique ID Chip Products".

Dallas/Maxim 1-wire products can use one shared (1 wire) bus for (virtually) any number of chips. To make this work, each such chip has a unique serial number. The simplest form of these chips has nothing more than this ID.

Wouter van Ooijen
  • 48,407
  • 1
  • 63
  • 136
  • Thanks @Wouter van Ooijen (+1) - a quick followup if you don't mind: are production programmers customizable (able to flash custom data), or are they standardized, in which case I would have to conform my program design around the capabilities of the programmer? – smeeb Aug 25 '15 at 14:05
  • You will have to check the programmer for details, I am not aware of any standards in this field. – Wouter van Ooijen Aug 25 '15 at 14:07
  • This was my solution. The production CPU flash routine splices the serial number into the ROM image (by replacing the magic constant in the compiled form). – Joshua Aug 25 '15 at 15:29
7

The way you describe is a valid one, at least it's one we use in our projects. First we flash the whole program which contains an initial set of values, so the program will run fine. During calibration the serial number (UUID) of the device will be set, along with the other calibration factors. For this we reserve a flash page at the end of the flash, so an update of the program is possible without erasing the calibration constants.

For this to work, of course, you need some way of communicating with the controller and a program part which will do the writing to the flash. If your product is not designed to have that, you have to inject that data during the initial flashing. For that you can change the hex file on the fly for each (the format is rather easy) or use capabilities of the flasher to include an automatically incremented serial number or something like that. The capabilities of the flashers are also quite different - for example, Segger produces some with quite good production programming capabilities.

If you just need a way to identify a device without a requirement for what that UUID has to look like, microcontrollers often have some device info in them, among others an ID. Whether that is usable has to be determined for every microcontroller type you use, as there is no standard that I am aware of.

For example the STM32F401 (a device I'm currently working with) has a 96-bit Unique Device ID which can be read by the CPU and with JTAG. (more details in the reference manual)

psmears
  • 678
  • 4
  • 6
Arsenal
  • 17,464
  • 1
  • 32
  • 59
2

There are devices for such purpose, for example this is the page for Maxim integrated for their PCB ID AND AUTHENTICATION products, which provide a factory-programmed, 64-bit unique ROM ID and I'm sure that there is other manufacturers that provide similar products

Kvegaoro
  • 3,141
  • 17
  • 14
1

Another ideal solution to this problem is to use one of Microchip's Serial EEPROM parts that come with a unique identifier programmed into them. These devices are small footprint I2C devices that you purchase ready to populate on your board like any other part. No special steps at manufacturing time are required. Simple I2C access can be used from your microcontroller and may not consume any additional resources on your board or MCU pins if you already have one or more other I2C devices on the board.

The parts from Microchip are primarily aimed at the Ethernet marketplace to supply the MAC Address for your device. Nothing prevents you however from using the unique identifier in other ways to serialize your product or to synthesize UUIDs from the code in the serial EEPROM.

Microchip commits a portion of the EEPROM device to hold the identifier and locks out the erasure and programming of that portion of the part. The rest of the EEPROM cells can be freely used of various other configuration data or calibration constants.

The part that I am using in my current design is the 24AA025E48.

Michael Karas
  • 56,889
  • 3
  • 70
  • 138
0

In addition to all the answers posted, some devices contain two separate memory: one large flash/EEPROM for the program and another smaller memory (typically just around 100 bytes or so) for data. For such devices you'd store the UUID in the data EEPROM.

They can be either programmed separately (I've seen devices where serial number and calibration data are flashed just before shipping to customers) or during the production run (you'd need a program, typically just a Perl script, to generate the UUID then pass it to the programmer).

slebetman
  • 1,660
  • 11
  • 14