Read Serial Number

lpcware · ‎06-15-2016

Content originally posted in LPCWare by briand on Wed Oct 20 15:01:42 MST 2010
Is there a register or memory location that can be read to get the processor serial number? I see this mentioned only from the external ISP interface.

Alternately, what's the best way to generate unique values in code for USB serial numbers? I don't want every device to have the same value or I won't be able to tell multiple devices in the same system apart.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ToBeFrank on Mon Jun 03 08:49:35 MST 2013

Quote: cyberstudio
So, after using only 32-bits from result_table[1] for a couple of reels, there has been some collisions, and we had to append result_table[3] to disambiguate. So, a minimum of 64 bits are required. If we find some way to shrink that any further I will give an update again.

This is the wrong way to do it. The only correct way is to use a hash. Here is a good analysis for you. It even includes a section as to why what you're doing is wrong.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Sat Jun 01 14:32:49 MST 2013
[FONT=Tahoma][SIZE=2]In our applications, we use the 1st (4K) flash sector as a (basic) bootloader.
I have written a customised and company specific utility similar to 'FlashMagic'
to install this bootloader via the ISP uart. [It is not difficult, all the required info
is in the user manual. Look at the ISP section, and there is an AppNote about
X-Modem encoding.] Remember to fix-up the boot block checksum also.

On Windows, the (template) binary payload can be added to the executable
(to avoid mistakes), or called up as an external file (for flexibility).

I reserve a certain number of address bytes within the booatloader for a serial
number. The PC installer alters the bootloader binary image before each and
every download to a new board to increment the serial number. Thus all of our
boards has a unique serial number. The PC app 'remembers' the last used number
in an ini file.

The serial number is at a fixed place in (low) flash memory, any user application
in other flash sectors can read the number easily in either assembler or "C" code.

If you need complete control over serialisation, you could do something similar.

I think that the paid for version of flash magic can do this.

As a complete alternative, serveral support chips will also have either a unique
factory serial number or an OTP (one time programable) region.
E.g. SPI/I2C data flash, some Dallas RTC chips, PLD's/FPGA's etc.

I hope that this will give some ideas about serialisation of production boards.

Cheers, Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cyberstudio on Sat Jun 01 13:29:08 MST 2013
I know it has been a long time but I still wish to update and preserve my learned lesson for the benefit of the lpc community.

So, after using only 32-bits from result_table[1] for a couple of reels, there has been some collisions, and we had to append result_table[3] to disambiguate. So, a minimum of 64 bits are required. If we find some way to shrink that any further I will give an update again.

By the way, is there any way to read and display the UID via the flash programming tool? (From the command line or GUI, from LPCXpresso or any other IDE?)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by domen on Thu Feb 09 04:43:17 MST 2012
Sound like crc16 or some hashing function would fit here.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by syzzer on Wed Feb 08 04:01:37 MST 2012
I do realize this is an old thread, but since I'm having the same kind of issue I'd like to add my observation here. I have two LPC1769 boards, with part ID's:

Device serial: 1919FC14 53540A45 4D966D6C F5000000
Device serial: 1717FC0E 53540DAD 4D96449D F5000005

As you can see, the 2nd and 4th 32 bits are quite equal to some of the parts of cyberstudio and pivic. So it indeed seams to make sense to avoid the 2nd and 4th 32 bits, as cyberstudio suggested earlier.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by pivic on Sat Jul 09 06:11:32 MST 2011
hi !

I'm finally back on this project !!

Reading the Unique ID from my LPC1114/302 I found:

result_table[1]0x202f316(d: 33747734 )
result_table[2]0x533608d7(d: 1396050135 )
result_table[3]0x4c75829f(d: 1282769567 )
result_table[4]0xf5000000(d: 4110417920 )

Anybody know which 32 bits is the safest to use ?
Collision are not a problem if the chance is low (1/1million).
Otherwise what algorithm could be used to compact the 128bits to 32bits?

@larryvc, not a SkyNet, It's for a wireless master/slave communication. :)

pivic

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Mon Apr 25 11:48:25 MST 2011

Quote: cyberstudio
It does not have to be universally unique, it only needs to be reasonably unique among the chips we purchase for our application. That is one or a few reels...

@cyberstudio, Does that infer that pivic will have to read all the chips first and then provide some ID based on the reel/lot that he uses in production? Doing a new production run after the first one with new reels/lots will most likely introduce many collisions.:confused:

@pivic, Are you building Sky Net?:rolleyes:

Hope we can help you figure this out.

Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cyberstudio on Mon Apr 25 11:19:24 MST 2011

Quote: NXP_USA
Unfortunately the details of what go into the 128-bit GUID cannot be disclosed. It can be said, however, that the 128-bit GUIDs are not random, nor are they sequential. Thus to ensure there are no collisions with other devices, the full 128 bits should be used.

It does not have to be universally unique, it only needs to be reasonably unique among the chips we purchase for our application. That is one or a few reels.

Note that it is okay for my application to collide with for example pivic's unrelated application. I am in an even worse position since I have only 16-bits to spare. All I am looking for is which 16-bits won't collide within 1 reel, or a few reels max, and even so, some collision is acceptable.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by pivic on Tue Apr 19 07:28:56 MST 2011
Hey all,

As I said earlier I don't actually need a unique unique number. Just a 32 bit ID that "ensures" no collision every 1million IDs. Which part of the 128bit can I use?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Mon Apr 18 10:47:37 MST 2011

Quote: TheFallGuy
I would guess that it is a Globally Unique Id:
http://en.wikipedia.org/wiki/Globally_unique_identifier

if you want a unique number, your are going to need to use all 128 bits...

Wow. Deja Vu.

pivic, it looks like you will have to do this. You could create an algorithm and extract what you need, but collisions may be inevitable.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by NXP_USA on Mon Apr 18 10:26:11 MST 2011
Unfortunately the details of what go into the 128-bit GUID cannot be disclosed. It can be said, however, that the 128-bit GUIDs are not random, nor are they sequential. Thus to ensure there are no collisions with other devices, the full 128 bits should be used.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by pivic on Mon Apr 18 02:28:31 MST 2011
That's a good idea,
I will read my UID's and post them. I've posted a message on NXP support but no luck....

To larryvc: The first time I did it was by using the IAP with Flashmagic, but it was only to verify the correctness of my reading using the code posted by Zero earlier in this thread (void read_serial_number(void)).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sun Apr 17 13:30:15 MST 2011
Hi cyberstudio,

It's been a little while since I was messing around with UIDs.

Did you use IAP to retrieve the data? If not what?

Are you Koshchi on another forum?

Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cyberstudio on Sun Apr 17 13:16:59 MST 2011
Simplest heuristic if collision is acceptable is to add the four 32-bit words together.

I guess if we experiment with enough parts we will be able to identify which 32-bits contains the most entropy. These are UIDs from the same chip, a LPC1114F/300, one coming from a LPCXpresso, and the other purchased from Digikey. The strange numbers are the markings on the chip.

01.131 ZSD09 470AY   88.101 ZSD10 400A
84216648   05050B48  16914196   01021714
1398089389 535526AD  1397886568 53520E68
1257279672 4AF090B8  1284782043 4C9437DB
4110417920 F5000007  4110417927 F5000007

As you can see, the last 32-bit appears to be constant. The second and third 32-bit words look similar - could be a lot number, reel number, whatever. I am sure LPC sells like hot cakes but still they are not going to fill up the Earth. Try your part out and post your UID. If we have enough data we may be able to determine what exactly is in an UID.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by pivic on Fri Apr 01 03:24:08 MST 2011
Ok thanks for the advice.
The reason for not using the 128bits is because I will send it on RF at 2.4GHz as part of a small message to identify where the message comes from. Using 128bits is largely overkill and take more time to send and I would like to use only one General Purpose Register to save it when I sleep (speed up the system at wake up).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Thu Mar 31 17:09:32 MST 2011

Quote: pivic
How can I get a non-guess answer?

I suppose you could ask about this at NXP tech support.

http://www.nxp.com/techsupport/index.php

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Thu Mar 31 09:33:21 MST 2011
Is there a strong reason why you can't use the full 128 bits?

It's already in the device and therefore you won't have to create your own ID.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Thu Mar 31 08:30:10 MST 2011
A GUID is only unique over all 128 bits. You cannot make any assumptions about that number is made up. So choosing a 32-bit quantity out of that is not going to be unique. It is up to you to decide on the risks of not being unique.

I'm no expert, but you might be able to perform some function on the full 128-bits that will give a reasonable uniqueness in 32-bits. Suggest you do some googling...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by pivic on Thu Mar 31 08:13:31 MST 2011
I don't really need a unique unique number. 1 over a million would be OK for the application, but not more. So I'm wondering if I use just the first 32bits of the unique ID it would be safe for me.

What would be your guess/idea? How can I get a non-guess answer?

Thanks

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Thu Mar 31 07:42:26 MST 2011
I would guess that it is a Globally Unique Id:
http://en.wikipedia.org/wiki/Globally_unique_identifier

if you want a unique number, your are going to need to use all 128 bits...