PICs with integrated serial numbers / unique ID codes

[DTJ]

I'm certain some 8 bit Microchip micro-controllers come with a  pre-programmed unique serial number.


I've looked at various data sheets on Microchips site and I've had  a look through their forum but I can't find anything.

Whats the key word I should be searching for??

thanks

[mikeselectricstuff]

Some of the higher end PIC32 ones definitely do so maybe look at the data for those to see what they call it.
"unique" is probably a good start for a search term.
 Microchip do offer programming services including serialisation - they call it SQTP
http://ww1.microchip.com/downloads/en/DeviceDoc/50002539A.pdf

They also sell eeproms with unique IDs for ethernet MACs

[DTJ]

Cheers Mike - I'm pretty sure I read about it in one of the spam marketing emails from E14 or some one.

My quantities are too low to bother with Microchip serialising them for me.

I'm trying to keep it simple and not add extra hardware, I might have to write something into eeprom myself post-programming.
 

[kony]

Older ones had ID EEPROM (4B long?), but that still had to be programmed by user (trough most reasonable programmers SW provided utility for incremental or pseudorandom IDs for production runs), in more recent ones this is ditched in favour of self-programmibility of flash, or larger EEPROM being present on the chip. The programmer tools (including free Microchip IPE) nowdays provide way to modify the flash binary by generated SN on specified adress, so it should be relativelly hassle free still. Look at SQTP under advanced settings of the IPE tool.

[BrianHG]

You can always make your software code on first power up, look at the flash and assign a number if empty.  Don't forget to protect the flash from programmer reading if you want to hide the serial number from third party cloning...

[dmills]

Any of the PIC32 parts with a built in MAC will have a unique MAC address that is accessible from software.

Regards, Dan.

[ElektroQuark]

Try searching for PIC IDLOCS. It may be what you are looking for.

[NorthGuy]

The newest ones have Device Information Area (DIA) which contains unique identifier (MUI). These are located at 0x8100 in program memory.

So far, the only ones with it are PIC16F153xx and PIC16F191xx where "xx" could be any 2 digits.

[mikeselectricstuff]

Or if its small qtys, use a programmer to do it - The ASIX programmers have extensive serialisation options

[JPortici]

About IDLOCS..
Good: Can be read even if device is read-protected (so perfect for firmware version / serial and such)
Bad: Only four bytes, at least on older enhanced mid range (PIC16F1xxx parts).

Not sure if you can also use the upper "byte" so have 4x14 bit. Manual says it shouldn't be possible.. but they are initialized as 0x3FFF when you erase the memory and then written as 0x00YY if you use
#pragma IDLOCx 0xYY

I also had Device Information Area in mind, i had read about it but couldn't find any reference to actual parts that use it. Glad to know that 16F153xx has it, they'll be at my desk very soon

[JTR]

About IDLOCS..
Good: Can be read even if device is read-protected (so perfect for firmware version / serial and such)
Bad: Only four bytes, at least on older enhanced mid range (PIC16F1xxx parts).

Not sure if you can also use the upper "byte" so have 4x14 bit. Manual says it shouldn't be possible.. but they are initialized as 0x3FFF when you erase the memory and then written as 0x00YY if you use
#pragma IDLOCx 0xYY

This is just a stupid legacy "hangover." You can indeed use the full range of bits on every baseline and mid-range PIC released in the last 25+ years if your compiler and programmer/bootloader handle it. Microchip tools tend not too support the full bit range.

The reason why microchip tools tend to only use the lowest nibble traces waaayyy back to the code protection method of the first 16C5x family where the three nibbles of the 12-bit IDLOCs were XORed together. The idea was to leave the upper two nibbles as '00' so the IDLOCs could be read by an external programmer even if the device was code protected. Some bozo at microchip decided that this lowest common denominator should apply to every generically related PIC henceforth. It just does not make any sense these days as the IDLOCs are not code protected anymore and even can be ported across erase/programming cycles and can be read at runtime by the firmware. There is no reason other than this stupid legacy issue that the full IDLOC cannot be used.

In the PIC32 with a unique serial number that I have seen the serial number is abbreviated as "UID" in the datasheet.

In any case, probably the quickest and easiest solution is what Mike suggested. A 3rd party programmer that supports adding serialization at program-time bypassing the artificial limitation imposed by microchip tools.

[DTJ]

OK - thanks for ALL of the information guys.

It looks like the device I'm using does not have any predefined ID values.
I'm already  using a serial interface to load some reference values into some EEPROM locations after the device is programmed so it looks like it would be easiest to simply extend this.
At least that way I can set the serial numbers at will after production and without any needing the programmer.

As usual I learn a lot from you guys! Thanks.

[westfw]

Some of the newer (formerly Atmel) AVR Microcontrollers contain a unique serial number.
ATmegaxx8pb, Attinyxx17, and all of the Xmega chips, for example.
(Alas, the unique serial numbers are never the "right size" to used as USB ID, or Ethernet MAC, or ... nearly anything else that "requires" a unique number.  You usually have to pick&choose or otherwise hash the bytes provided, and hope for the best.  (The AVR serial numbers appear to be 9 bytes, for example.))

[ElektroQuark]

But they are not PICs, OP asked specifically for PICs

[TomS_]

Another potential option:

https://datasheets.maximintegrated.com/en/ds/DS2431.pdf

These have a factory burned-in (literally, with a laser, according to the datasheet) 48 bit unique identifier with CRC, making up to 56 bits total.

There is an application note which describes how to discover what this value is:

https://www.maximintegrated.com/en/app-notes/index.mvp/id/187

[JPortici]

About IDLOCS..
Good: Can be read even if device is read-protected (so perfect for firmware version / serial and such)
Bad: Only four bytes, at least on older enhanced mid range (PIC16F1xxx parts).

Not sure if you can also use the upper "byte" so have 4x14 bit. Manual says it shouldn't be possible.. but they are initialized as 0x3FFF when you erase the memory and then written as 0x00YY if you use
#pragma IDLOCx 0xYY

This is just a stupid legacy "hangover." You can indeed use the full range of bits on every baseline and mid-range PIC released in the last 25+ years if your compiler and programmer/bootloader handle it. Microchip tools tend not too support the full bit range.

The reason why microchip tools tend to only use the lowest nibble traces waaayyy back to the code protection method of the first 16C5x family where the three nibbles of the 12-bit IDLOCs were XORed together. The idea was to leave the upper two nibbles as '00' so the IDLOCs could be read by an external programmer even if the device was code protected. Some bozo at microchip decided that this lowest common denominator should apply to every generically related PIC henceforth. It just does not make any sense these days as the IDLOCs are not code protected anymore and even can be ported across erase/programming cycles and can be read at runtime by the firmware. There is no reason other than this stupid legacy issue that the full IDLOC cannot be used.

In the PIC32 with a unique serial number that I have seen the serial number is abbreviated as "UID" in the datasheet.

In any case, probably the quickest and easiest solution is what Mike suggested. A 3rd party programmer that supports adding serialization at program-time bypassing the artificial limitation imposed by microchip tools.

I JUST programmed the OTP in some dsPICs using the IPE
It was written in the datasheed that the upper byte should be kept at 0xFF for the config words, so they would result in a NOP in case they are excecuted by accident.
I would guess this is also the reason because #pragma IDLOCx uses only 8 bits

Then, assuming the same was true for the OTP memory i kept the upper byte at 0xFF, also because i could then access the serial numbers with PSV (cani? i haven't checked, i assume i can)
but the god damn IPE decided to pack the data so
- can't see the whole thing withjust  PSV. Not a tragedy, but still..
- what if WANTED to write 0xFF?? In this case i used ASCII characters for the serial number so i'm good, but still..
that really pissed me off and i did NOT expect that to happen. The IPE manual doesn't mention it.