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 (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
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
That way I get 32 more bits 🙂
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 🙂
MCU on Eclipse 
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!
LikeLike
I have used the unique ID with Processor Expert code for years and it always worked well. With migrating to the SDK function I did not notice the fact that the upper 32bits always were zero 😦
LikeLiked by 1 person
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.
LikeLike
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.
LikeLike
It is described in each reference manual of the STM32 sub-family, for example at page 925 of the RM https://www.st.com/resource/en/reference_manual/dm00031936-stm32f0x1stm32f0x2stm32f0x8-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
I have never thought of analyzing the fab performance this way, interesting.
Best regards
LikeLike
Hi Carl,
thanks for sharing. I must have missed that when using STM parts as I was assuming they don’t disclose it. Very well done by STM. It is actually a good sign if such details are provided, because that way I can decide for my application which parts I want to use for my own purpose.
LikeLike
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.)
LikeLike
Hi Paul,
yes, as far as I can tell the K series has 4×32 (128bits) and the L series has only 80bits.
LikeLike
You might be interested in the little survey I did of unique ID capabilities of various MCUs: https://flit.github.io/2020/06/06/mcu-unique-id-survey.html
It’s interesting to note the diversity of UID sizes, and the surprisingly small sizes in certain families.
LikeLike
Hi Chris,
yes, this is indeed very, very interesting, thanks for sharing!
Erich
LikeLike
Hi Erich – Isn’t this a bug? Shouldn’t the processor-specific header file define the symbol(s) expected by the SDK?
Thanks as always and Happy Holidays!
Best Regards, Dave
LikeLike
Yes, this is a bug imho, and I have reported it to NXP. I hope this gets fixed soon.
Happy Holidays!
LikeLike