Unique device ID (and flash size)

Post your cool example code here.
User avatar
RogerClark
Posts: 7173
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Unique device ID (and flash size)

Post by RogerClark » Wed May 27, 2015 1:02 am

Guys,

This code may be useful to someone .


Its possible to read the size of the Flash memory and more interestly a unique device ID

Code: Select all

void setup() {
Serial.begin(115200);
}

void loop() {
  uint16 *flashSize = (uint16 *) (0x1FFFF7E0);
  uint16 *idBase0 =  (uint16 *) (0x1FFFF7E8);
  uint16 *idBase1 =  (uint16 *) (0x1FFFF7E8+0x02);
  uint32 *idBase2 =  (uint32 *) (0x1FFFF7E8+0x04);
  uint32 *idBase3 =  (uint32 *) (0x1FFFF7E8+0x08);
  
  Serial.print("Flash size is ");
  Serial.print(*flashSize );
  Serial.println("k");
  
  Serial.print("Unique ID is ");
  Serial.print(*(idBase0),HEX);
  Serial.print(*(idBase1),HEX);
  Serial.print(*(idBase2),HEX);
  Serial.println(*(idBase3),HEX);  

  delay(500);
}
One of my mini maples has this code

FF486735451864987103035

and another one has

FF5466A5449846767251545


So the code does appear to work.

keshavadk
Posts: 1
Joined: Mon Jul 25, 2016 6:54 am

Re: Unique device ID (and flash size)

Post by keshavadk » Mon Jul 25, 2016 7:00 am

Can i know why device ID starts from address 0x1FFFF7E8 and why it should be incremented with 2 for four times. like 0x1FFFF7E8+0x02, 0x1FFFF7E8+0x04, 0x1FFFF7E8+0x04
0x1FFFF7E8+0x08

User avatar
RogerClark
Posts: 7173
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Unique device ID (and flash size)

Post by RogerClark » Mon Jul 25, 2016 7:36 am

Everything is normally documented in the STM32F103 reference manual RM0008 page 1079

(Google for it)
Unique device ID register (96 bits)
You probably could read this as three 32 bit reads,. I'm not sure why the example code read the first register in two 16 bit chunks
However, the reference manual says it can be read in single bytes or 16 bits at a time if required.

madias
Posts: 813
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: Unique device ID (and flash size)

Post by madias » Mon Jul 25, 2016 12:31 pm

Hm. My first thinking about an unique ID is setting up a NRF24L01 network and every node is the ID, so you wont have to think about different node names. I just hope that "our" STM32F01 are really *unique* and not chinese clones with the same ID :)

User avatar
ahull
Posts: 1630
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Unique device ID (and flash size)

Post by ahull » Mon Jul 25, 2016 12:33 pm

madias wrote:Hm. My first thinking about an unique ID is setting up a NRF24L01 network and every node is the ID, so you wont have to think about different node names. I just hope that "our" STM32F01 are really *unique* and not chinese clones with the same ID :)
You could of course also try writing to those registers... Unlikely, but not impossible that they might be writeable as well as readable. It would be much simpler to put the ID in a small block of flash, given there are already flash blocks on the chip, than to put in OTP ROM cells. (OTP ROM would take up less dies space, but given the relative sizes on the die these days, that might not be a consideration). Of course, you might need to set some other register bit to allow writing, and that might be the secret sauce we don't have.
- Andy Hull -

User avatar
RogerClark
Posts: 7173
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Unique device ID (and flash size)

Post by RogerClark » Mon Jul 25, 2016 9:43 pm

Andy

I agree, those registers are probably writable, but you would need to know what other registers to access in order to make them writable. They are likely just to be a private block of Flash that may also contain other info that its not accessible outside of the MCU.

The MCU must have special blocks of flash to hold the internal bootloader, though I suppose those could be part of the die; But if I was designing a MCU with its own internal SW, I would be very tempted to put that code in some private flash.

Of course that would mean each chip needs to be flashed, but I presume each chip needs to have its ID set, unless it has some magic first run code that samples environmental data to generate the ID - and that sounds fraught with problems unless the device contains a dedicated random number generator based on a noisy resistor etc

zmemw16
Posts: 1449
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: Unique device ID (and flash size)

Post by zmemw16 » Mon Jul 25, 2016 9:52 pm

couldn't you just do it at the wafer level?
if they can generate programmed eprom/efuse then a serial number can't a problem.

srp

User avatar
ahull
Posts: 1630
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Unique device ID (and flash size)

Post by ahull » Mon Jul 25, 2016 10:01 pm

The unique ID is probably programmed during the testing phase. After all, all of the other elements of the system need tested (ram, flash, peripherals etc.) so an additional routine to set a serial number would not significantly impact on the testing time.
- Andy Hull -

User avatar
RogerClark
Posts: 7173
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Unique device ID (and flash size)

Post by RogerClark » Mon Jul 25, 2016 11:02 pm

ahull wrote:The unique ID is probably programmed during the testing phase. After all, all of the other elements of the system need tested (ram, flash, peripherals etc.) so an additional routine to set a serial number would not significantly impact on the testing time.
Ah.

If they test all the flash, then flashing the bootloader to a private flash would also not take hardly any more time, as they would need to do at least 2 erase and write cycles to test 1 and 0 in every "bit" of the flash

User avatar
ahull
Posts: 1630
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Unique device ID (and flash size)

Post by ahull » Tue Jul 26, 2016 7:09 am

RogerClark wrote:
ahull wrote:The unique ID is probably programmed during the testing phase. After all, all of the other elements of the system need tested (ram, flash, peripherals etc.) so an additional routine to set a serial number would not significantly impact on the testing time.
Ah.

If they test all the flash, then flashing the bootloader to a private flash would also not take hardly any more time, as they would need to do at least 2 erase and write cycles to test 1 and 0 in every "bit" of the flash
Bear in mind that JTAG was developed specifically to "verify, design and test" circuits and devices, so there might also be a vendor specific JTAG option to set the UUID, and write the bootloader.
- Andy Hull -

Post Reply