32F417 CPU ID, and creating a product S/N out of it

[peter-h]

This hack to read the CPU ID

Code: [Select]

uint8_t uid[12];
uint8_t idbuf[30];

for(uint8_t i = 0; i < 12; i++)
{
    uid[i] = *(volatile uint8_t *)(UID_BASE + i);
    sprintf((char*)&idbuf[i*2],"%02x",uid[i]);
}

debug_thread_printf("CPU ID= %s",idbuf);

produces

Code: [Select]

4c004a001550484e52333620
260052000751383131363834

on two different CPUs, so it looks fairly random if not completely random (bytes 1 and 2 both 0x00, and most bytes being printable). This is unlike the "unique ID" of some other chips which is only partly variable.

Has anyone here used this to generate a S/N for their product from this?

Curiously I found an article saying the CPU ID is not CPU accessible on the M4 Cortex and you have to use DMA to read it!

[nctnico]

I used such a unique ID to create a serial number from consisting of 0-9 and the alphabet without the vowels so you don't run the risk of creating a serial number with foul language.

[sokoloff]

It depends on the constraints you want for the product SN.

If you're willing to have a 20 character SN, you could use the numbers 2-9 and capital letters excluding I and O so each position encoded 5 bits, making the 12 bytes take 20 characters without any excessively similar letters.

If the user would never really have to type it, you could make it shorter by including lowercase, symbols, etc. and could easily get 6 bits per character (16 character SN) without any risk of a hash collision whatsoever.

[DC1MC]

I used such a unique ID to create a serial number from consisting of 0-9 and the alphabet without the vowels so you don't run the risk of creating a serial number with foul language.

31137FKKR

[Zero999]

I used such a unique ID to create a serial number from consisting of 0-9 and the alphabet without the vowels so you don't run the risk of creating a serial number with foul language.

31137FKKR

b1tch c00n d1ck

[peter-h]

Excellent

I have moved on to the Adesto AT45DB321 security register and get this

Code: [Select]

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1501041632131F2701010F00FFFFD6FF
30303050593346310E360FFFFFFFFFFF
40404040404040404040404040404040
40404040404040404040404040404040

On another device:

Code: [Select]

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1501041631361F2701010E00FFFFEAFF
30303050593346310E2E0FFFFFFFFFFF
40404040404040404040404040404040
40404040404040404040404040404040

It looks right, even though the majority of the variable part (the second half) is obviously worthless:

[newbrain]

I used such a unique ID to create a serial number from consisting of 0-9 and the alphabet without the vowels so you don't run the risk of creating a serial number with foul language.

FCKNGG00D idea.

[Siwastaja]

Matter of taste. I have done CRC32 over the 48-bit (or whatever) "unique ID", then use hexadecimal to convey it to users. 8 characters is OK-ish, and hexadecimal has the benefit there are no similar-looking characters like 1 and I or 0 and O. Plus of course, for programmers, it's easy for mental conversion. You could use full alphabet and remove all ambiguous characters but then you would have maybe some 32 symbols available, just 5 bits per symbol instead of 4.

Unless you are selling in millions, it's extremely unlikely to get two identical 32-bit IDs.

[peter-h]

A CRC32 is a great idea.

Some products have a label which carries the (possibly random) S/N as a barcode.

The challenge with this is that you can't simply record which S/N range went to a particular customer - for product recall purposes. Many years ago we shipped hundreds of Product X with a 22uF 25V tant cap fitted backwards. It ran on just 5V so didn't catch fire unless the ambient went to +60C, which I just happened to be testing by pure coincidence! We were able to recall nearly all of them, by S/N ranges.

With a non-sequential S/N you need a database which holds info on who got which numbers.

[SiliconWizard]

Or if you want something less "obvious" than a CRC32, you could use some PRNG and seed it with the CPU ID, and then run it for one or more iterations and use the end value.

But yes, in any case, you'll need a database, so that doesn't solve much compared to generating SNs during production. Why not make it a step after flashing the firmware, program the SN in Flash and call it a day?

To be fair, there is a benefit not programming SNs in Flash memoryn but using something fixed: making them impossible to modify or erase. I've used unique ID chips in the past for that. But if the "CPU ID" you refer to is guaranteed reasonably unique, then it's the same.

Whatever you do, having a database with your production info is a good idea.

[peter-h]

Or if you want something less "obvious" than a CRC32

"Less obvious" is a tough job in an embedded system unless you have blown the security fuses, because any "key" will always be discoverable by disassembly. Well, unless you have a smart card chip there, but that's hassle for a simple thing like this.

having a database with your production info is a good idea.

It makes sense if most or all of your products are serialised. Many years ago, another company, we had a system developed which did the whole tracking job end to end, running on, believe it or not, an AS/400. Barcode scanners, etc. Eventually it was abandoned due to complexity.

making them impossible to modify or erase

IME, this is a real point. We had customers dismantling the units and exchanging the part of the case which had the S/N sticker on it, to get a S/N which was still within warranty (they were blowing them up due to wrong installation, etc). I caught them out because we also wrote the S/N into an EEPROM.

In this case the S/Ns come off a printed sheet of stickers, obviously sequentially, and the person doing the production test enters the number into a factory test dialog. I think I will stick with this system. Stuff like the CPU ID is useful for some anti counterfeiting measures