How can I use the UID registers on a K8x MCU to derive a 32-bit UID?

[deniscollis]

Hi,

Does anyone know how the K8x SIM->UID* register values are determined when set in the factory. 

My dev board has these: 

SIM->UIDMH: 1232535582
SIM->UIDML: 200705
SIM->UIDL: 923029061

How can I use these to derive a unique 32-bit UID.

(Experience from other manufacturers' chips is that the factory values typically include a batch-number, and/or wafer serial# + position on wafer, and/or ROM programming date-stamp, and or unique chip serial#.  Once the bit-splicing is known, it is usually quite easy to reduce these 128- or 96-bit values to a 32-bit UID.) 

Thanks,
Denis

[deniscollis]

Thanks @ErichStyger , @bobpaddock - Using the QSPI flash ID or a CRC32 are both good ideas.

We use different flash vendors, so that option will need to include a vendor ID, leaving fewer bits for the rest of the serial number. 

For CRC32, how do we find the probability of a hashing collision without access to a large population of valid Kinetis UIDs?

Lastly.  Actually, I don't really need to know how the Kinetis UID is structured if NXP themselves could provide a reduction algorithm without revealing the fields.

[bobpaddock]

I was hoping @ErichStyger could look at the data he has already collected.

The properties that make CRC good for error detection, generally make for bad hashes. It is just commonly available code.

[ErichStyger]

My understanding is that silicon vendors do not provide that information, how that UID is built up.

Background: It is as well my understanding that it contains date/time information, some kind of wafer identification, plus some kind of x and y coordinates on the wafer. So if you know the decoding, you can pick a roll of parts (assuming they are coming from consequent wafers) and you get the waver yield value (assuming the missing parts were bad parts), something usually Si vendors keep as a secret.

We had as the same challenge as you (how to reduce the number of bits of the UID). What we did: we used a roll of 1000 parts and checked out the UID numbers. From the numbers we identified the numbers which are always the same, and did not include these numbers in the 'unique vector generator'. This 'unique vector generator' then is stored as configuration data on the batch of devices to be used to create the new (smaller) UID. For every new batch of parts, this process is repeated and updated.

In another project, we are using an external SPI flash for storage: there we are using the unique ID of the flash device for the device unique ID, combined with the UID of the Kinetis.

I hope this helps,

Erich

[bobpaddock]

> My understanding is that silicon vendors do not provide that information, how that UID is built up.

NXP has stated they consider the information proprietary..
Always putting up road blocks to designing in their parts from my perspective.

>  This 'unique vector generator' then is stored as...

Have you ever done anything like CRC32 of that data set to see the likelihood of collisions?

Once the non-changing bits are removed, does a 32 bit CRC or Hash give enough collision free values to be useful directly?