Help wanted: Reading the serial number from AVR using USERSIG.h

[rvdbreemen]

I want to read out the serial number from the sig row, using the USERSIG.h functionality. I only get FFFFFFFFFFFFFFFFFF in return. So I am wondering what I am not seeing...

Here is my code, any insights?

#define LEN_SERIALNUMBER 16 
uint8_t avr_serialnumber[LEN_SERIALNUMBER-1]={0};
char avr_serialnumber_hex[LEN_SERIALNUMBER*2]={0};

char* getAVRserialnumber(){    
    // 7.6.2.3 Serial Number Byte n
    // Name:  SERNUMn
    // Offset:  0x10 + n*0x01 [n=0..15]
    // Reset:  [Byte n of device serial number]
    // Property:  -
    // Each device has an individual serial number, representing a unique ID. This can be used to identify a specific device
    // in the field. The serial number consists of 16 bytes: SIGROW.SERNUM[15:0].
    // Bit 7 6 5 4 3 2    

    char buf[5]={};
    avr_serialnumber_hex[0]=0; //clear string
    for (int i=LEN_SERIALNUMBER-1; i>=0; --i)
    {
        avr_serialnumber[i] = USERSIG.read(0x10+i);
        sprintf(buf, "%02X", avr_serialnumber[i]);
        strlcat(avr_serialnumber_hex, buf, sizeof(avr_serialnumber_hex));
    }
    Monitor.printf("Serialnumber: [%s]\r\n", avr_serialnumber_hex);
    return avr_serialnumber_hex;
}

Looking forward to a solution that fixes my work.

[grandaspanna]

By way of preface, I'm not an expert on this, but two things...

There's an example in the core that uses this approach:

volatile uint8_t *mptr = &SIGROW_SERNUM0;
  showHex(*mptr++);
  for (byte i = 0; i < 15; i++) {
    Serial.print(':');
    showHex(*mptr++);
  }

Just did a quick test using the SIGROW.SERNUMn references directly and get data (on a 128DA32):
uint16_t serno = SIGROW.SERNUM1<<8 | SIGROW.SERNUM0;

[rvdbreemen]

That's a great find, thanks for that. That helps fixing it. Makes me wonder what the use of the USERSIG.h wrapper is, I guess people will use it to right to SIGROW, but for me I only want to get the 16 byte serialnumber, that's all.

[SpenceKonde]

The disappointingly named USERROW and SIGROW are to us mere mortals, completely totally different except for the fact that they are non-volatile memory in the data space. That tis he only thing they haven in common
USEROW - A small amount of memory which has no function defined y the hardware. It can be used as the user plaseases.. In addition to simple methods,. through special and convoluted means it can be written even when the chip os locked, in order to enable or dissave features depending on how badly the customer needs it and how much money the customer has on hand and how much iof that you think you can shake em down for. Depending on whether you're the customer or manufacturer and how you implemented this , this could be trivial to reverse engineer, or effectively impossible. As I intentionally do not understand crtypto I am ill-placed to comment further.
On a more mundane note, the User Signature Space can be used much like EEPROM - with the exception that it stays there unless a chip errase is performed on a locked chip or a your code explicitly erases it directly. See the following table of types of memory on modern (post 2016) AVRs:

Erased	FLASH	EEPR0M (no EESAVE)	EEPROM (EESAVE)	USERRROW	Fuses	Lockbitss	SIGROW
Chip Erase	Yes	Yes	No	No	No	Yes (only as the final step, once other applicable memory is erased)	No
Manual erase	Yes (unless locked)	Yes	Yes	Yes	No	No	No
Write via bootloader	As much as needed to fit the new program only	No	No	No	No	No	No

The SIGROW is a separate section of NVM. This is mostly empty on the Dx-series. however. it contains critical (and mysterious!) information on the tinyAVR 0/1/2 parts. There it contains multiple calibration constants. bit iot also contains wacky undocumented parameters, which I have made precious little progress elucidating.There are constants which stay constant for the entire pincount, regardless of how much or how little ram it has,. There are several; mysterious numbers that must be used for something (they are typically centered around some value, within a very narrow range around it - as if it were calibration constant of some sort.But what? Who could say? See https://github.com/SpenceKonde/AVR-Research/ repo for some info and a collection of sigrow data.

whatever the case, to us mere mortals - the SIGROW is read-only (though I would wager a fistfull of hundos that there exists a KEY that can be used to enable writes to it (less sure about erases) and other areas of the memory used to configure the chip based on economic and demand considerations and the results of factory testing. In fact, I think it's likely that AVR16DD's and tinyAVR 42x chips could be told that they were actually 32k or 8k respectively - assuming you knew the magic KEY to enable that interface, there was a way to erase what was already there (if there';s no way to erase, you can bet your ass that changing a 16k chip to a 32k one would involve changing a 0 to a 1, which can't be done without erase, while changing a 1 to a 0 is just a write. Naturally if you had this info, in order to get his fist full of Ben Franklins, you'd need to demonstrate this in front of me and not notice that I'd hooked up the UPDI line to a datalogger, so you'd basically be selling me the master key for a pitiance ;-) Anyway, short of such wizardry - you cannot write to the SIGROW. Don't bother trying,. human sacrifice doesn't work. (We have tried with both virgins and even a non-virgin- (hey, don't look so surprised, tell me how hard a time you would have finding a non-virgin embedded developer vs a virgin one?). Neither seemed to make a dent in the matter, unfortunately,)

. There are at least 3 non-public 64-bit keys I belive, 2 relating to OCD, and the likely sigrow one There may be an extra one that enables more registers for testing purposes. These are and are likely the kind of number that, if you were an outsider who knew it, could casually mention around Microchip staff at a loud event and watch as everyone turned towards you and the room got silent enough to hear a pin drop. Whether you made it out of the room intact with a suitcase full of cash or the CEO ordered security to execute you is another matter.
The unique serial number is stored sin the SIGROW, not the USERSIG (recall that you can rewrite the userow with arbitrary data, so it would not be much of a unique serial number would it? See modernRevSer example included with the core for a demonstration of how to read all the information from the sigow.

Note also (as described in the memories section of the datasheet) the SIGROW and USERSIG (or much more commonly USERROW - We'd have have named the library that except it was a;ready taken by the header file

There is no library for accessing the sigrow, that functionality is built-in. see
See the headers sectioned the docs for the full description:

Search for SIGROW in your parts' header file and you'll find that a struc named SIGROW is already there. ex:

typedef struct SIGROW_struct
{
    register8_t DEVICEID0;  /* Device ID Byte 0 */
    register8_t DEVICEID1;  /* Device ID Byte 1 */
    register8_t DEVICEID2;  /* Device ID Byte 2 */
    register8_t reserved_1[1];
    _WORDREGISTER(TEMPSENSE0);  /* Temperature Calibration 0 */
    _WORDREGISTER(TEMPSENSE1);  /* Temperature Calibration 1 */
    register8_t reserved_2[8];
    register8_t SERNUM0;  /* LOTNUM0 */
    register8_t SERNUM1;  /* LOTNUM1 */
    register8_t SERNUM2;  /* LOTNUM2 */
    register8_t SERNUM3;  /* LOTNUM3 */
    register8_t SERNUM4;  /* LOTNUM4 */
    register8_t SERNUM5;  /* LOTNUM5 */
    register8_t SERNUM6;  /* RANDOM */
    register8_t SERNUM7;  /* SCRIBE */
    register8_t SERNUM8;  /* XPOS0 */
    register8_t SERNUM9;  /* XPOS1 */
    register8_t SERNUM10;  /* YPOS0 */
    register8_t SERNUM11;  /* YPOS1 */
    register8_t SERNUM12;  /* RES0 */ // res 0-3 mean reserved, and will likely be used at some point in the future. 
    register8_t SERNUM13;  /* RES1 */
    register8_t SERNUM14;  /* RES2 */
    register8_t SERNUM15;  /* RES3 */ 
    register8_t reserved_3[32]; /* Note: The last two bytes are not "reserved" they appear to be a checksum. */
} SIGROW_t;

Clearly the signature row is written during the factory calibration process when the chip is told how many pins if has connected to it, as well as what the default oscillator cal byte should be....

The fact that all other reserved bytes on Dx-series parts within the sigrow are blank; suggests that information configuration settings here is somewhere else between 0x0000 and 0x3FFF (between the start of the address space, and the start of SRAM, because after that, it's all used for known purposes and can be arbitrarily set by the user.

A more practical takeaway from the translation of a Dx SIGROW posted earlier in this message? If you want to get a high entropy value from the sigrow, you need to run it through a srs business hash function, because of the 16 bytes, only a dozen contain values, the lot numbers increase sequentially over time, and so are the same for parts produced around the same time at the same factory (very low entropy), X and Y almost certainly have patterns in them that would show up if on analyzed enough chips, and scribe likely does too. The numbers also look to be BCD for many fields further constraining the number of possibilities. So dnt rely on this to generate your private key or something