Getting a 96bit Unique ID for each Kinetis Device using MCUXpresso SDK

The NXP Kinetis devices implement a UID (Unique ID) for each device, using the ‘Unique Identification Register) which is part of the SIM (System Integration Module):

SIM Unique ID

SIM Unique ID (NXP K22P144M120SF5RM.pdf Reference Manual)

While this number should be unique, I was wondering last week why students in the labs reported the same UID for multiple robots in the lab. So maybe this number is not so unique as it should be?

Such a ‘unique ID’ has been implemented by most silicon vendors I’m aware of it, but usually there is no information available from the vendor how this ID is built up. I’m using that number for track or identify boards. For example I’m using the ID to build up a hash as a device address or with a list of IDs and hardware revisions in the firmware I can keep the firmware the same, while it can do different things depending on the ID.

I’m using the McuLib in combination with Processor Expert or the MCUXpresso SDK to report the UID, for example it can be displayed on the console:

UID reported

UID reported

Using the Processor Expert code I have never observed that two IDs were the same.

For the NXP MCUXpresso SDK v2.8.2 I’m using the SIM_GetUniqueID() function:

 
void SIM_GetUniqueId(sim_uid_t *uid)
{
#if defined(SIM_UIDH)
    uid->H = SIM->UIDH;
#endif
#if (defined(FSL_FEATURE_SIM_HAS_UIDM) && FSL_FEATURE_SIM_HAS_UIDM)
    uid->M = SIM->UIDM;
#else
    uid->MH = SIM->UIDMH;
    uid->ML = SIM->UIDML;
#endif /* FSL_FEATURE_SIM_HAS_UIDM */
    uid->L = SIM->UIDL;
}

Shortly it was clear why students reported multiple MCUs with the same ID: because the above function only uses the MH, ML and L but *not* the H part because SIM_UIDH has not been defined :-(.

At least the fix is easy: make sure that SIM_UIDH is defined in the project settings, e.g. in the compiler settings:

SIM_UIDH defined in compiler settings

SIM_UIDH defined in compiler settings

That way I get 32 more bits 🙂

Full 96bits for UID

Full 96bits for UID

In essence: if you are using the MCUXpresso SDK and depend on the UID: make sure you have SIM_UIDH defined in the project properties, otherwise the UID is missing 32bits. Now I’m getting the full 128 bits instead only 96.

Happy uniquing 🙂

Links

12 thoughts on “Getting a 96bit Unique ID for each Kinetis Device using MCUXpresso SDK

  1. Interesting – I experienced the same thing as your students and wondered about that.

    It wasn’t an issue for me because I was looking for the device information and not the UID.

    Thanx!

    Like

  2. Hi Erich,
    For your information, on the STM32, the unique ID (also 96 bits) is usually a mix of X and Y coordinates on the wafer, the wafer number and the lot number.

    Best regards.

    Like

    • Hi Carl,
      yes, this is my thinking as too. Is this information official somewhere? The Kinetis has a 128 bit UID (only 96bits are exposed by the SDK without the extra #define).
      I believe the vendors do not disclose how the number is constructed it would give competitors information about the factory efficiency.
      So if you know say where the wafer number is and the x and y coordinates: buy a roll of parts and if they are not mixed up completely, you can tell from the missing numbers the yield rate of the wafer. Not that would be interesting for developer, but maybe for the analyst?
      From a developer point of view it would be helpful to know how the number is built up, because that way I could select the part of the ID which would be most useful to build an ID for a product.

      Like

  3. Good catch.
    It looks like your K22 has 128b UID since there are 4x 32-bit registers, no?

    I’m about to use the KL05’s UID in a new product. I just double-checked and the manual says it only has 3 registers for UID (SIM_UIDL, SIM_UIDML, SIM_UIDMH) and only the lower 16-bits of Mid-High register are unique. So I have a total of 32+32+16= 80b. Then I’m using CRC32 to hash it into a 32-bit uniformly-distributed random number so it can be used for a node-discovery algorithm on a LIN network. (I’m only using 24 bits of it. According to the “Birthday Problem” https://en.wikipedia.org/wiki/Birthday_attack I determined the chance of a 24b UID collision in a network of 16 nodes is extremely small ~ 1/140k.)

    Like

Leave a Reply to Paul Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.