Device Signature compsition on STM32

[xaela]

Posted on July 30, 2009 at 21:01

Device Signature compsition on STM32

[xaela]

Posted on May 17, 2011 at 13:15

Hi Guys...

I am facing a request from a customer of mines, he requested to use the internal STM32 device electronic signature to create an unique application Serial Number... As the Application Serial Number is just a 32 Bit field, I would like to know exactly the composition of the 96 bits field Device signature inside the STM32 device so that I can create an unique 32 bit field... Should I assume it's just a simple incremental number counting thru all 96 bits...? May be some fields are subdivided by Device family and so on...? Found no clues in this forum or in any doc... Tnx for any info... Alex [ This message was edited by: E-Redeemer on 26-06-2009 09:50 ]

[xaela]

Posted on May 17, 2011 at 13:15

Hi St7...

Tnx for the suggestion... Sadly, it's a Math rule, there is no way to get 32 bits of unique numbers scaling down from 96 bit numbers, whatever algorithm you may use... The application will use this code for Network identification over a full country WAN, so, quite possible to have conflicts this way... So, only way is to know what fields in the 96 bit ID are really incremental, and which ones may be not, and eventually build up an algorithm based on such informations... Alex

[st3]

Posted on May 17, 2011 at 13:15

If you can't get a suitable answer to your question, perhaps you could just feed the 96 bits through a CRC32 algorithm (or similar) and use the 32-bit CRC result...?

[16-32micros]

Posted on May 17, 2011 at 13:15

Hi ,

You should use all the 96-bits data, the Unique ID it is not built to just incrementing number but is completely random using STMicro factory algorithms for all produced devices. Cheers, STOne-32.

[xaela]

Posted on May 17, 2011 at 13:15

Ok, tnx for the Info STone

I will check better into this problem then, as, sadly, the system is already established as using just 32 bits as requested by the customer... Regards... Alex

[jellybean10025]

Posted on May 17, 2011 at 13:15

This is a big problem for us too. We have our users read the serial number off our display for various service and support reasons. They can usually get 8 hex digits right, and even 16 is possible. But getting users to read out or email a 24 character hex number without mixing up B and 8 or D and o is brutal.

We ship thousands of units and a conflict would trash our serial number tracking system. :-[ :( There is no way to consistently reduce the number of bits through compression of a random bit stream, but if this isn't truly random throughout all 96 bits, there are possible solutions. It appears that U_ID(31:16) is reserved for future use. Is this really needed for uniqueness? Are there other parts that encode information that isn't necessary for uniqueness? If anyone has a cunning suggestion, I'd love to hear it. [ This message was edited by: jellybean10025 on 29-07-2009 23:39 ]

[domen2]

Posted on May 17, 2011 at 13:15

How about some 32-bit hash?

Collisions should be RARE. And if you insert the numbers before shipping to customers you could just discard that 1 device 😉 For ethernet applications you already need 48-bit unique MAC, so there you could use that. Ditto for bluetooth.

[xaela]

Posted on May 17, 2011 at 13:15

Hi Domen...

Hashing may be an Idea, but without exactly knowing digit weights into the 96 bit ID, it may run into having more number collisions than expected... Problem with ethernet MAC, is that the devices are able to get into WAN also by GPRS or other medias apart ethernet, so, an ethernet device could be not mounted on some versions of the device, so, bye bye MAC number... That's why customer would like to use the micro ID, as the micro, for sure, is always mounted on the board... Tnx for your time and suggestions... Alex

[trevor1]

Posted on May 17, 2011 at 13:15

If you're using GPRS modem then you could also use the modem IMEI number if you always have Ethernet or GPRS fitted.