Undocumented signature row contents

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spun off from another thread.

david.prentice wrote:
Ah-ha. I haad never thought of reading 'other' Signature row bytes !

Sure enough. I tried some chips (sig #0x0E - #0x17):

Huh. I'd never thought of it either.

I whipped up a little program to read the signature bytes for all values of Z, and fed it through hexdump -C:

-------------------------------------------------------------------------------
00000000  1e a5 95 ff 0f c9 ff 26  ff 0a ff 17 ff ff 47 30  |.......&......G0|
00000010  33 35 33 34 ff 12 0a 19  17 01 12 01 13 01 ff ff  |3534............|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff 2c 06  |..............,.|

These 128 bytes repeat until:

00007e00  01 01 01 01 01 01 01 01  01 01 01 01 01 01 01 01  |................|
*

... and then the whole smash repeats again at 0x8000.

One sees the signature bytes at 0x00, 0x02, and 0x04, as well as the calibration byte at 0x01 as expected. The 96 bytes from 0x001E through 0x007D and some of the rest are all 0xFF and presumably 'empty', but the remainder of them appear to indeed contain consistently readable data which survives a reset and a power cycle, suggesting they are not the result of a random reset or power-up condition such as with SRAM.

Checking a second 328P:

00000000  1e a0 95 ff 0f ca ff 26  ff 0c ff 17 ff ff 58 32  |.......&......X2|
00000010  35 30 31 35 ff 15 21 06  17 02 12 06 13 06 ff ff  |5015..!.........|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff 6e 03  |..............n.|

It gives similarly consistent results, but these additional bytes are by and large different from the first device.

Quote:
Note that the first six bytes are human-readable.
They appear to be more than that!

The underside of the first 328P has the following markings:

0G5343-1
35473D
1-p1036 e3

The underside of the second 328P has the following markings:

2X0551-2
35473D
1-p1252 e3

Note that the first line with each character pair transposed matches the 'human readable' signature row bytes 0x000E through 0x0013 for both devices. A curious convolution.

Quote:
I have no idea what anything means.

I have been unable to find details about precisely what the printing on the bottom of the package means. I can infer from correspondence with Atmel about the ATtiny85 that the first line is the fab and lot number, and the third line is a date code and revision, but I don't consider this to be gospel.

Does anyone know definitively what the bottom markings mean?

Here's a comparison of these extra bytes, not counting the block of 0xFF, nor the individual 0xFF, nor the already identified string of 6. Bottom markings are repeated for reference:

       |  1st 328P  |  2nd 328P  |
       |------------|------------|
       | 0G5343-1   | 2X0551-2   |
       | 35473D     | 35473D     |
       | 1-p1036 e3 | 1-p1252 e3 |
       |            |            |
  addr | hex  dec   | hex  dec   | same   speculation
-------|------------|------------|-----------------------
0x0005 |  C9  201   |  CA  202   |        ?
0x0007 |  26   38   |  26   38   |   y    ?
0x0009 |  0A   10   |  0C   12   |        year
0x000B |  17   23   |  17   23   |   y    ?
0x0015 |  12   18   |  15   21   |        ?
0x0016 |  0A   10   |  21   33   |        ?
0x0017 |  19   25   |  06    6   |        ?
0x0018 |  17   23   |  17   23   |   y    ?
0x0019 |  01    1   |  02    2   |        1st line suffix
0x001A |  12   18   |  12   18   |   y    ?
0x001B |  01    1   |  06    6   |        ?
0x001C |  13   19   |  13   19   |   y    ?
0x001D |  01    1   |  06    6   |        ?
0x007E |  2C   44   |  6E  110   |        ?
0x007F |  06    6   |  03    3   |        ?

I've indicated where the bytes are the same on both devices. Given that these two devices are probably from different fabs, and appear to have been manufactured more than 2 years apart, I might guess that those bytes which are the same on both devices are perhaps the same on all 328Ps. Of course, some of those bytes might be the MSB of a timestamp or unit number.

Some speculation, based solely on these two devices:

- byte 0x0009 is the year in the date code
- byte 0x0019 is the '-N' suffix of the first line.

And that's about all my brain can see.

Anyone have any thoughts? Is all of this rubbish? Has it already been deciphered and reported on years ago?

If anyone cares, I'd be curious what other members are able to find in 'signature space', and how it correlates to markings on the package, especially if anyone has several devices with identical markings. Also useful would be two more devices with identical markings except for the date code. I can post the program I used to generate the above output, but it's pretty simple.

A useful result would be if the revision of the device could be inferred from a byte in signature space. Another might be if we can be reasonably sure that the signature row or some part of it is indeed unique for each device.

I tried the same thing when reading the fuses and lock bits from software (i.e. against all values of Z). No hidden data was evident, only the same 4 bytes repeated.

I'll look at a few more 328Ps (and some ATtiny85s) later...

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i also saw a claim somewhere that there were undocumented programming commmands for WRITING some of the supposedly read-only locations. For instance, the oscillator calibration value...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
i also saw a claim somewhere that there were undocumented programming commmands for WRITING some of the supposedly read-only locations. For instance, the oscillator calibration value...
I would expect that this would be a production requirement. How else is the calibration byte to be placed within the device in the first place?

I always imagined the cal byte write was done before packaging, and that there was perhaps a test point on the die used to enable the write, making it impossible to alter after packaging. Perhaps it's simpler than that, and it's just an undocumented timed sequence.

Do you have a link?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would guess that the Signature Row is writable under certain circumstances. I possess an AT89S52 that has a broken Signature. I have no idea how I managed to corrupt it! I have never seen an AVR with broken Signature.

The AT89 parts have undocumented bytes in their Signature rows too.

Of course, Atmel Flash devices can read the Signature from SPI or HVPP. Only the modern AVRs can read via LPM.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting, here are the results for a 1284p.

extended signature:

"X27664" FF 09 1A 11 17 continues-->(01 12 06 13 06 FF FF FF FF etc.)

chip backside:

2X6746-35452B
1-F1250-83

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ront1234 wrote:
Interesting, here are the results for a 1284p.
extended signature:

"X27664" FF 09 1A 11 17 continues-->(01 12 06 13 06 FF FF FF FF etc.) 
 chip backside:

2X6746-35452B
1-F1250-83 

Thanks!

In the two 328P I tested, the last two bytes in each 128-byte block (addresses 0x007E and 0x007F) were also non-0xFF. What were yours? If you'd care to post the whole 128-byte block, that would be neat...

I wonder if the 2nd line on the backside is a device code... EDIT: whoops, looks like your first line corresponds to the 1st and 2nd line on the 328P.

As for the last line, are you sure the suffix is '-83' and not '-B3'?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Feb 22, 2014 - 02:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
If you'd care to post the whole 128-byte block, that would be neat...

As for the last line, are you sure the suffix is '-83' and not '-B3'?

Here's the 128 bytes. I think you're right about the '83'. Looking under my shop lighted magnifier it appears to be 'e3' the bottom tail of the 'e' curves up and 'almost' closes to become an 8.

1E 91 97 FF 05 FF FF FF FF FF FF F7 FF FF 58 32
37 36 36 34 FF 09 1A 11 17 01 12 06 13 06 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
1E 91 97 FF 05 FF FF FF FF FF FF F7 FF FF 58 32
37 36 36 34 FF 09 1A 11 17 01 12 06 13 06 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Hmmm... I note that bytes 0x7E and 0x7F are 'FF' unlike in the two 328P's I posted. I wonder if 1284P has a longer block? Perhaps 256 bytes? Or longer?

I've examined 4 other 328Ps. The back-side first line of each one lacked the single-digit suffix present on the first two. Likewise, they all had more 'data' in the extended signature.

Importantly, 3 of the 4 had identical markings on the back, but significant portions of the extended signature were different:

0J3411                    
35473D                    
1-P1107 e3                    

0x0005 | 0xD0  208    | 0xCB  203    | 0xC4  196    |
...
0x0007 | 0x26   38  & | 0x26   38  & | 0x26   38  & | same
...
0x0009 | 0x07   7     | 0x0A   10    | 0x08    8    |
...
0x000B | 0x17   23    | 0x17   23    | 0x17   23    | same
...
0x000E | 0x4A   74  J | 0x4A   74  J | 0x4A   74  J | same
0x000F | 0x30   48  0 | 0x30   48  0 | 0x30   48  0 | same
0x0010 | 0x34   52  4 | 0x34   52  4 | 0x34   52  4 | same
0x0011 | 0x33   51  3 | 0x33   51  3 | 0x33   51  3 | same
0x0012 | 0x31   49  1 | 0x31   49  1 | 0x31   49  1 | same
0x0013 | 0x31   49  1 | 0x31   49  1 | 0x31   49  1 | same
...
0x0015 | 0x16   22    | 0x17   23    | 0x16   22    |
0x0016 | 0x0D   13    | 0x0D   13    | 0x13   19    |
0x0017 | 0x1D   29    | 0x24   36  $ | 0x2A   42  * |
0x0018 | 0x17   23    | 0x17   23    | 0x17   23    | same
0x0019 | 0x01   1     | 0x01    1    | 0x01    1    | same
0x001A | 0x12   18    | 0x12   18    | 0x12   18    | same
0x001B | 0x05   5     | 0x05    5    | 0x05    5    | same
0x001C | 0x13   19    | 0x13   19    | 0x13   19    | same
0x001D | 0x05   5     | 0x05    5    | 0x05    5    | same
...
0x002E | 0xAA  170    | 0x88  136    | 0xD3  211    |
0x002F | 0x8B  139    | 0x89  137    | 0x87  135    |
0x0030 | 0x81  129    | 0x9D  157    | 0x9E  158    |
0x0031 | 0x59   89  Y | 0x56   86  V | 0x55   85  U |
0x0032 | 0x1F   31    | 0x20   32    | 0x55   85  U | 
0x0033 | 0x67  103  g | 0x65  101  e | 0x63   99  c | 
0x0034 | 0x95  149    | 0x83  131    | 0xAC  172    |
0x0035 | 0x94  148    | 0x91  145    | 0x8D  141    |
0x0036 | 0x9A  154    | 0xC6  198    | 0xAD  173    |
0x0037 | 0x4A   74  J | 0x48   72  H | 0x47   71  G | 
0x0038 | 0x5B   91  [ | 0xD9  217    | 0x2D   45  0 | 
0x0039 | 0x76  118  v | 0x75  117  u | 0x72  114  r | 
0x003A | 0xA5  165    | 0xDD  221    | 0xE3  227    |
0x003B | 0x1B   27    | 0x24   36  $ | 0x25   37  % | 
0x003C | 0xB8  184    | 0x55   85  U | 0x3B   59  ; | 
0x003D | 0x0D   13    | 0x0E   14    | 0x0E   14    |
0x003E | 0x64  100  d | 0x9B  155    | 0x60   96  ` | 
0x003F | 0x1B   27    | 0x24   36  $ | 0x25   37  % | 
...
0x007E | 0x41   65  A | 0xC1  193    | 0xE5  229    |
0x007F | 0x2B   43  0 | 0x30   48  0 | 0x2C   44  , | 

Again, not much that my brain can decode, apart from the character-transposed fab/lot of the first line in bytes 0x000E through 0x0013.

I wonder if there is a unit number in there somewhere. Perhaps a 32-bit value from 0x0015 through 0x0018.

Even if there isn't a block of bytes which is completely unique to each individual device, it would seem at least possible that the extended signature could be used to generate a UUID for use by app code.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a thought (I haven't been following this). But Xmega document some of their "signature". I have a sneaking suspicion it's probably just documenting what already existed and had previously been used in tiny and mega. One of the "interesting" values (I always think) is the X,Y location of the die on the wafer for example.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Just a thought (I haven't been following this). But Xmega document some of their "signature". I have a sneaking suspicion it's probably just documenting what already existed and had previously been used in tiny and mega. One of the "interesting" values (I always think) is the X,Y location of the die on the wafer for example.
Good idea.

I've had a look at (probably older versions of) the AU and D manuals. Never looked at the XMEGA family before. Somewhat daunting :?. Looks like Device ID signature isn't part of the production signature row, but is part of the MCU control block of registers in the Peripheral Module Address Map.

Apart from lots of calibration data, the production signature itself contains a 6-byte lot number perhaps akin to the character-transposed 6-byte field that mirrors the fab/lot on the first line on back-side of the ATmega.

It also contains as you mentioned a 1-byte wafer number, and two 2-byte coordinates.

These 11 bytes form the device's 88-bit serial number.

Let's assume as you suggest that the wafer number and coordinates exist in and are similarly mapped w.r.t. the fab/lot field in the ATmega. The first byte of the fab/lot field in the ATmega is 0x000E, while the first byte of the lot number in XMEGA is 0x08.

There's no good reason to believe that the relative offsets of the fab/lot, wafer, and coordinates will be the same, but let's try anyway ;). Thin ice, to be sure...

Nevertheless, walking out onto this thin ice we can guess that on the ATmega the wafer number is at 0x0016, and the X-Y coordinate words are at 0x0018-0x001B. Looking at my previous post it's clear that this can't be, since bytes 0x0018-0x001B are identical across all three devices.

If a wafer number and coordinates are indeed contained within the signature row, I'm not certain how they can be unambiguously identified.

Also unexplained is why the 4 of the 6 devices I examined appear to have 18 extra non-'empty' bytes.

There are bytes which remain constant across all six devices:

0x0007  0x26
0x000B  0x17
0x0018  0x17
0x001A  0x12
0x001C  0x13

Exactly what this reveals is not clear of course...

When I have more time to burn, I might dig deeper.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow George! Nice work!

I found especially fascinating the thread with posts by KKP.

I wonder how much of this can be done via ISP or HVPP, or even SPM.

It also begs the question of how much of the signature row is actually erasable/writeable. The suggestion is the whole page, i.e. 128 bytes on the ATmega328P. This may also explain why @ront1234's 128-byte signature dump for the ATmega1284P appeared to be incomplete. The flash page size for that device is 256 bytes.

Keeping in mind:

Quote:
The higher undocumented sig/cal bytes may or may not have interesting control functions Smile
... and:
Quote:
Beware: Like the documented keep_eeprom_during_chiperase fuse, there is also an undcumented bit somewhere, 'keep signature rows during chiperase'; During some of my experimentation I managed to erase it on one of my devices and I haven't been able to find it, thus every time I do a normal chiperase the signature of this particular device is erased too.
... I nevertheless wonder if user data could be placed into unused portions of the signature row. However this is less interesting to me than identifying the information that is stored at the fab. I'm mostly interested in this identification for use as a ready-made UUID, and the possibility that a chip revision might also be in there somewhere.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've examined 5 ATtiny85s. As expected, the extended signature row is the same size as the flash page size: 64 bytes.

Four of the devices have the same back-side markings. I've indicated where a byte is identical across all 5 devices, or just the four with the same markings.

Note that the 6-byte field which in the ATmega328P was clearly a little-endian ASCII encoding of the fab/lot on the 1st line of back-side printing appears in the ATtiny85 to be a placeholder: 'unknow' for the 4 similar devices, and '0T0000' in the 5th.

In the 4 similar devices there are only 2 bytes which appear to be unique (apart from the calibration bytes not included below).

       | 1F7   415          | 6H6   951
       | B5     1P          | B4     1P
       | 1236   e3          | 1115   e3
-------|--------------------|-------------
0x0008 | e7  e7  e7  e7     | e7     
0x0009 | f7  f7  f7  f7     | f7     
       |                    |      
0x000E | 6e  6e  6e  6e  n  | 54  T
0x000F | 75  75  75  75  u  | 30  0
0x0010 | 6e  6e  6e  6e  n  | 30  0
0x0011 | 6b  6b  6b  6b  k  | 30  0
0x0012 | 77  77  77  77  w  | 30  0
0x0013 | 6f  6f  6f  6f  o  | 30  0
       |                    |      
0x0015 | 00  00  00  00     | 10     
0x0016 | 14  1b  2b  2c     | 15  
0x0017 | 17  21  18  1a     | 09  
0x0018 | 17  17  17  17     | 17     
0x0019 | 20  20  20  20     | 20     
0x001A | 12  12  12  12     | 12     
0x001B | 03  03  03  03     | 00     <1F7>
0x001C | 13  13  13  13     | 13     
0x001D | 03  03  03  03     | 00     <1F7>
0x001E |                    | 9c  
0x001F |                    | 3c  
       |                    |           
0x0032 | 7f  7f  7f  7f     | 7f     
0x0033 | 01  01  01  01     | 01     

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
This may also explain why @ront1234's 128-byte signature dump for the ATmega1284P appeared to be incomplete. The flash page size for that device is 256 bytes.

The signature page is 256 bytes since the data didn't repeat in the last 128 bytes. However, from 0x80 to 0xff all bytes are 0xff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Giorgos_K wrote:
The documented and undocumented memories erasure opcodes posted previously are of the ISP protocol.
I'd missed this:
A Hellene wrote:
the undocumented erase_cal_space opcode is '0xAC 0xC0 0x00 0x00'.
... but had seen this:
KKP wrote:
This is via the HV programming logic; If someone maps it out on the other methods, I would like to learn too.

To erase the signature and calibration rows, modify your programming software so that bit7 of the first instruction byte of chiperase is set. That is, the sdi/sii pairs
80,CC 00,64 00,6C
Will erase the signature and calibration rows.
...
After you have erased the signature and calibration rows, load the flash programming instruction, followed by 16 words of data as one usually would for programming flash. Then, instead of executing flash_load_high_address_page_program, load
sdi 1xx1 x011 0000 0000 0000 0000
sii 0101 0101 0100 0101 0011 0101
instead (let's call it sig_page_program).

Quote:
It is just another FLASH memory page, that can be accessed in the standard read-modify-erase-write fashion. Nothing special involved, apart from the magic WRITE_SIGNATURE_SPACE opcode.
Which is what, exactly? ;)

Quote:
Joey, since you seem to be genuinely enjoying the whole thing, let me give you a few more calibration space data dumps from my archives for your statistics:
Thanks George!

I will be looking at these before too long.

Cheers,
JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does this mean that it should be possible to change the cal byte in tinys/megas? Dump the signature space, change the calibration value and write it back?
It would be really nice having the right calibration without having to store a value in the EEPROM (which has to be protected from acidential overwrites).