Unique 96bit ID meaning and its shortening

[kinovicf]

Posted on February 08, 2013 at 08:06

Hello.

I have a question concerning processor 96bit UID. I understand that this number is ST unique number and I would like to use it as a board identification in production. But the number is farly long for expressing in text form. So I would like to short it to be unique relative for certain chip. I see that DFU boatloader uses a shorter serial number similar to UID and it differs among similar chips. Would anybody know the number meaning  or a mask reducing the number to demanded purpose? Thank you. #id-unique-meaning-shortening

[waclawek.jan]

Posted on February 08, 2013 at 08:29

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fstm32F205%2096%20unique%20ID%20use%20only%2032&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FF...

[linkfix] https://community.st.com/s/question/0D50X00009XkZEeSAN/stm32f205-96-unique-id-use-only-32 [/linkfix]

[kinovicf]

Posted on February 20, 2013 at 09:13

Hello.

Thanks for the link. The 96bit UID looks to be combination of lot number, waf number and X,Y position on it. I found out how DFU serial number is probably created (tested on some chips F2 and F4). Here is example for F4 (UID expressed hexadecimally in MSb (bits 95-0)) : UID: | 31 34 35 33 | 31 31 47 0B | 00 23 00 38 | and DFU s/n: ''3157356B3131'', where: ''31'' = 0x31 (bits 95-88) ''57'' = 0x34 (bits 87-80) + 0x23 (bits 23-16) ''35'' = 0x35 (bits 79-72) ''6B'' = 0x33 (bits 71-64) + 0x38 (bits 7-0) ''31'' = 0x31 (bits 63-56) ''31'' = 0x31 (bits 55-48) It is a question if the same serial number could be created from different lot number and X, Y position.

[Tesla DeLorean]

Posted on February 20, 2013 at 19:06

It is a question if the same serial number could be created from different lot number and X, Y position.

Always hard to represent a 96-bit value using 24/48-bits. I don't think anyone here has enough data to provide a through solution. I wouldn't rely on a truncated value being unique. Output the number in base64 or something, surely 16 characters can't be too much to handle on the test/pc side.

[emalund]

Posted on February 20, 2013 at 20:21

I do not know about this chip, but previously - with another chip - asking ''your'' question, the reply was ''we can in no way guarantee anything re using a shortened number''.

I would be VERY weary of using a partial number. anyhow, if this might be a solution Mzxim has a <$0.50 ''unique serial number'' chip (If I recall DS1452) that only uses 48 bits Erik

[kinovicf]

Posted on March 25, 2013 at 11:25

Thanks for the posts. I have already decided not to ignore any data of 96-bit number.

[Andrew Neil]

Posted on March 25, 2013 at 15:31

''I would be VERY weary of using a partial number''

You should be very wary of using a partial number - otherwise you are likely to become very weary of the consequences...!

;)

[denis]

Posted on September 24, 2013 at 16:16

Just to make sure: ST provided libs do not define some magic macro / function for this uid (or address of)  (and flash size ..), without me coding in the number from the manual?

(just in case there is a macro/func I can't find, i've searched UID on all their support lib for f10xxx ..  but other family also prob have uid? f2xxx ? )

[Tesla DeLorean]

Posted on September 24, 2013 at 17:19

Just to make sure: ST provided libs do not define some magic macro / function for this uid (or address of)  (and flash size ..), without me coding in the number from the manual?

(just in case there is a macro/func I can't find, i've searched UID on all their support lib for f10xxx ..  but other family also prob have uid? f2xxx ? ) I'm not aware of a macro, the addresses are different across each series, and sometimes within (L1). The different parts also have different ROM(OTP) locations. Read the documentation carefully, observe the non-linear addressing. I would certainly try to sanity check the FLASH size value before accepting the UID, and have the code warn on the part, as well as any test fixturing app if it saw any anomalies or duplicated UID. The UID is not acceptable as a MAC address, but could be used in encryption related to key or salting applications. Storing your own GUID and/or MAC in OTP is probably another way to go. I think the key take away is to OWN and VALIDATE your solution, and not abdicate that to any ST library function.

[denis]

Posted on September 25, 2013 at 12:17

>I'm not aware of a macro, the addresses are different across each series,  ...different ROM locations.....

Precisely : I thought such macro/func of theirs should do, have right address depending on my device (depending on my project macro i guess...). I find lots of, imho 'useless' little funcs in that ST lib, like a function to read CCR1 register for example. >and sometimes within (L1) What is L1 ? Low power mode family?