Byte 0x0E - 0x17 of SIGROW

[techstudio-design]

Spencer,

I found out that for bytes 0x0E to 0x17 of SIGROW, it contains the Lot Number, Wafer Number and X, Y coordinates (of the chip silicon on a wafer). It is disclosed on How to read serial number in AVR by Microchip.

**Addr --------- Description**
0x0E --------- Lot Number 2nd Char
0x0F --------- Lot Number 1st Char
0x10 --------- Lot Number 4th Char
0x11 --------- Lot Number 3rd Char
0x12 --------- Lot Number 6th Char
0x13 --------- Lot Number 5th Char
0x14 --------- Reserved
0x15 --------- Wafer Number
0x16 --------- Y-coordinate
0x17 --------- X-coordinate

Noted that the 1st char is at 0x0F instead of 0x0E, and it further mentioned that the above "format may be used to read the Serial number for the Mega and Tiny devices".

This lead me to think that the example code for reading the serial might not be in the correct order as well.

I have a batch of two new chips coming in, and I'm going to find out more to see if I could some consecutive numbers.

[SpenceKonde]

Those are two very interesting documents (the one you linked and the list of parts with such a a serial number that it links to)

As usual from Microchip when matters that relate to the 2016 revolution (the AVRe+ -> AVRxt transition, which happened at the same time as Atmel was bought out), the document provides less clarity than you would hope for.

1. It is difficult to reconcile what is stated in that document with the one in links to which claims to say which parts have such a signature.

a. The assembly code presented is for an AVRe/AVRe+ part; note the reference to SPMCSR and the old style of constants.

b. The other document indicates that the only classic AVRs that had the serial number were the PB's (the last classic avr parts in the megaAVR series to be released). I do not think that is actually the entire list - I'm pretty sure at least some of the last gasp of classic tinyAVR do as well - but the only way anyone is going to find out is by systematically taking a bunch of classic AVRs and reading out their sigrows to see if there's anything there other than the device ID and OSCCAL value. Documentation regarding signature space beyond the device ID is thin to non-existent for most parts. Almost every device that supports self programming can read it's own sigrow, for example, to find the factory calibration value for OSCCAL - though many of them do not have SIGRD defined in the IO headers. Some of them do not mention it in the datasheet (these aren't correlated either - I've not found any classic AVRs that don't give you the the OSCCAL factory value when you try to read it out, but for many parts it's not documented, and/or isn't in the header (so boot_signature_byte_get() won't compile), and on a few parts, the constant has a different name, but the same numeric value, so code is incompatible unless it uses the number instead). I think that mess should be papered over in ATTinyCore 2.0.0 (or rather, I think it is done in 2.0.0-dev, and if it's not, it will be before I release it) But I think the most recent released version of ATTinyCore, now somewhat old, still had the first version of the code to read the default OSCCAL value from certain parts (I think it was a micronucleus board so the bootloader might have changed the cal value to tune it based on USB timing, in order to upload a sketch over USB, so we needed to know what the original was and set it back to that if the user selected the normal speed, rather than the usb-tuned speed, which would be a pretty normal thing to do - the benefit of running at the slightly different speed was only that VUSB libraries would work, except that they largely don't, because we can't meet the timing constraints of USB without sacrificing (or radically reengineering) millis because, without a way to make the USB interrupt able to interrupt other interrupts (like we can do on modern AVRs), making vUSB functionality work in an arduino sketch is more dream than reality. The way they make it work spectacularly well for uploading is that they don't have to do anything else..... but I digress) has something like this in it (from memory):

(somewhere several layers of #if's deep, such that that only a couple of parts were being picked up - all of which happened to not have SIGRD in their io headers)
byte SIGRD = 5; //don't remove this line 
uint8_t default_calibration = boot_signature_byte_get(some address);

which works because that is a macro, not a function that boot.h provides. The proper fix, of course, is to just provide the define in Arduino.h, which is what is done in ATTinyCore 2.0.0).

Aaanyway....
I am always interested in details of the SIGROW, as they certainly didn't make it obviously accessible before the advent of modern AVRs (when they unified the address space, that made reading the signature row much less of a dark art) even though it's only handful of instructions to read it, and I'm certain that there are intriguing gems to be found there. The classic t841, 441 and I suspect the 1634 and 828, have more in the sigrow than most classic parts, probably including a serial number....

But you are asking in regards to the modern AVRs (AVRxt devices, presumably a tinyAVR 0/1/2-series) - not that the documentation for modern AVRs covers every byte of it, but it's a hell of a lot better than it was in the bad old days. That document applies directly only to the older parts (yes, I know they didn't clearly state that; but they never do a good job of differentiating what I call "classic AVR" and "modern AVR". They don't even have an official terms for them, despite the fact that nearly everything was changed except the instruction set - my hope is that my terms will eventually enter universal use. I don't have a particular preference for my terms, and if tomorrow Microchip stated that they would use some different pair of words for the two classes of AVR I would be happy to toe the line. The lack of official clarity muddles what should be a goddamned simple subject) On the modern parts, the serial number starts immediately after the device ID, not at address 0x0E within the SIGROW (which also isn't a separate address space.

/* Signature row */
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 SERNUM0;  /* Serial Number Byte 0 */
    register8_t SERNUM1;  /* Serial Number Byte 1 */
    register8_t SERNUM2;  /* Serial Number Byte 2 */
    register8_t SERNUM3;  /* Serial Number Byte 3 */
    register8_t SERNUM4;  /* Serial Number Byte 4 */
    register8_t SERNUM5;  /* Serial Number Byte 5 */
    register8_t SERNUM6;  /* Serial Number Byte 6 */
    register8_t SERNUM7;  /* Serial Number Byte 7 */
    register8_t SERNUM8;  /* Serial Number Byte 8 */
    register8_t SERNUM9;  /* Serial Number Byte 9 */
    register8_t reserved_1[11];
    register8_t OSCCAL16M0;  /* Oscillator Calibration 16 MHz Byte 0 */
    register8_t OSCCAL16M1;  /* Oscillator Calibration 16 MHz Byte 1 */
    register8_t OSCCAL20M0;  /* Oscillator Calibration 20 MHz Byte 0 */
    register8_t OSCCAL20M1;  /* Oscillator Calibration 20 MHz Byte 1 */
    register8_t reserved_2[4];
    register8_t TEMPSENSE0;  /* Temperature Sensor Calibration Byte 0 */
    register8_t TEMPSENSE1;  /* Temperature Sensor Calibration Byte 1 */
    register8_t reserved_3[30];
} SIGROW_t;

Note that those reserved values are not all blank on tinies (though they largely are on Dx-series), and some of them vary within a narrow range from part-to-part - almost certainly that has meaning. There's a text file in this repo that maps it out.

But what I don't know is how to interpret it (that serial number sketch does not claim to decode the lot number or other properties - I just print it out as hex there, because the documentation is insufficient to decipher it.

One thing that is clear is that at least on modern AVRs (I haven't checked classic ones) some but not all of the 10 byte serial number should not be treated as a byte taking value 0 to 255 - I think parts of it are ASCII text - but then there are also non-printing characters there, so some of the serial number bytes are appropriate to treat as byte values.

I encourage you to look at the text files in this repo, particularly sigrows_6-8-21.txt - which contains the whole sigrow section from I 28 or some-such ATtiny1626's, and I mapped it in one of the other files (like, just pulling together all the applicable information I could find from various sources as applies to tinyAVRs on this mysterious section. Unlike Dx-series parts, where it's just about empty except where the io header shows it as having meaning, the tinyAVR sigrow is chock full of values (mostly constants, and that vary, each over a very narrow range) of uncertain significance.)

As to whether a proper interpretation of these values would have the bytes flipped (a consequence of endianness somewhere, I imagine). one would have to look at sigrows from different points in time, and hope to find that there was a way to interpret them that produced monotonically increasing values. At least the chip shortage means that we can be pretty confident that an parts we manage to get our hands on weren't sitting around for long. Even when MicroChip Direct has it "in stock" they list a date when they can ship it, and it's not the next day. I have received packages from them containing 2 separate tubes of the same part, individually shrinkwrapped, and dated on successive days. The only plausible explanation is that they put all the ones they had into a tube, shrinkwrapped and labeled it, then the next day when they could complete the order, they put the remaining part of the order into another tube, and shrinkwrapped it. Note that - of course - as parts come off the production line, ones that big buyers pre-arranged to purchace (up to 3 years in advance) get priority. In times of shortage like these, we are but mice looking for crumbs.

[techstudio-design]

I'm aware that the code the link that I shared refer to the old boot.h. I'm kind of thinking that the data it mentioned would probably applicable for tinyAVR series 0/1/2 as not many old chips have the serial number in it.

Anyway, my purpose was to share the information that I found, and hope collectively we will get better insights down the road.

BTW, here are some of the SIGROW dump for the chips that I have. I have 10 more each of 824 and 3227, but they are not mounted on PCB yet, so don't have the information yet.

ATtiny824

1E93293041505353 4979E3350CFF3C0F
05FFFFFF1208FFFF B2053404FFFFE0F8
8901FFFFFFFFFFFF AEF4E3FC1FFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFE70D

ATtiny3227

1E952630434D4E32 436886381FFF430D
06FFFFFF1308FFFF B9033803FFFFE0F8
88EFFFFFFFFFFFFF AEF4E3FC1FFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFF1B75

ATtiny3217

1E95225151415439 2073AA1123FF410F
05FFFFFF16071706 57069706D606EFF8
8BEB0209080EFFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 2013671E20FF3D10
06FFFFFF15071B04 5B049905D805EFF8
88D4060D040BFFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 2053821925FF3E0F
05FFFFFF15081606 56069606D506EFF8
8BE3FD040209FFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 20B3540626FF3D10
06FFFFFF18071805 58059705D605EFF8
88C70810FE05FFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 2013494A24FF420E
06FFFFFF14061306 53069306D206EFF8
88D2FD050309FFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 2053784226FF4010
05FFFFFF14061506 55069406D306EFF8
84C2040DF900FFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 2093362C24FF400F
05FFFFFF13071506 55069406D306EFF8
87CB070EFC02FFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 2033B22821FF4110
05FFFFFF14071406 54069406D306EFF8
86D60007060CFFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

1E95225151415439 20F3994E23FF410E
05FFFFFF15071B03 5B039904D804EFF8
89F1020B0810FFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF

[SpenceKonde]

Thank you!

The information coming out of microchip is pretty much as clear as mud on these matters..... We already have confirmation (thanks to you), it would seem that:
constants vvvvbbbb and aaaaaaaa are constant across te whole 2-series, and any deviation from them would be exciting news.
Your more recent samples seem to confirm that they're not including oscillator error values on 2-series now :-(

That's actually a major bummer for me. I know the values were like +/- 1 or 2, but that would have made the self-tuning that much more accurate (I've got a sketch partly done that calculates tuning values for the 6 potentially reachable speeds out of 10, 12, 16, 20, 24, 25, 30 amd 32 MHz by assuming perfect tuning (including error on the 0/1-series and time the inaccurate 32 khz clock from it, then uses that as a reference while varing the internal HF cal from 0 up until either 255 or the chip crashes. It stores the best values for each speed n the USERROW like is done currenty by the included tuning sketch (which requires a reference clock to tune against). I need to finish that and see how close it gets, If it's close enough

And yes, particularly if you use F-spec parts, 32 MHz @ 5v and room temp on a 2-series generally works.

Oh - those parts you gave specs for - do you remember if they're N's or F's? I want very dearly a way to tell the two apart once I've taken them out of the package. It is not marked on the outside of the chip. It'd be mighty nice if it were in the SIGROW at least! Otherwise, the only way you can figure it out is by asking Microchip support about a lot number (and despite the fact that I'm a huge unpaid evangelist for their latest products, they still treat me like I have the IQ of a houseplant, so I don't like dealing with them. If I were in production and was specifying F=spec parts, I would try going through noting all the lot numbers used and emailing them about them because I need to "keep my production partners honest").

Which seems really really dumb for a critical spec like that. With these chips being rated for life safety critical applications I would consider it negligent to not have a way for the firmware to keep the production partner honest about the chips they were using by checking if they're actually the F-spec chips rated to run at 125C or just normal N-spec chips guaranteed only up to 105. (No, I have not been able to figure out F and N abbreviations. on the Dx the're either I (industrial) or E (extended). N might be for "normal", but F? "Fucking hot" while accurate seems a little unprofessional) I actually do have an application where I'm pretty sure I will need to crank Dx chips up to 40 MHz (and hence will want E's). It's one of those times where a critical parameter of the result is dependent only on the number of CPU cycles in a given length of time.

If for some reason you're processing speed bottlenecked? For fun? I dunno. I do know that I added 27 MHz to DxCore specifically because a group of enthusiasts of something that involved radio wanted to share a clock also used for some sort of radio communication chip, which for some dumbass reason is 27 MHz.

[techstudio-design]

The Series 2 parts that I have are ATtiny824-SSU, and ATtiny3227-MU. Both have temperature range of -40 to +85 degree Celsius. The ATtiny3217 are ATtiny3217-MN which has a temperature range of -40 to 105 degree Celsius.

Believe it or not, I was told by my friends in the semiconductor industry that whether a part is categorised with extended temperature range or normal range is based on testing, it could come out from the same wafer, those able to meet the high specification get marketed as the extended range parts, and those are marginal would be priced and marketed as normal temperature range...

[SpenceKonde]

Holy shit I had never noticed that the 2-series was F-spec and U-spec.... Ya know, somehow those two letters seem appropriate for their having lopped 20 degrees off the maximum operating temperature of the cheaper version,....

Yeah, that's my understanding of how they do it too. And depending on how good their process is, it is common for companies to end up adjustting the bins such that parts that are perfectly good at high temps end up in the low bin because of relative demand. Obviously, since they can sell F-spec chips with 6-10 month leadtimes, this isn't happening right now. Presumably it happens during the factory calibration phase, so they should be able to write something to the sigrow about it!

(BTW - The DB extended temp can be pushed all the way to 48 MHz with an external clock, at least on some specimens. 2:1 on the system clock! PLL also seems to work at 128 (from internal 32, using the undocumented 4x multiplier option) still seems sto work. but 160 (40 MHz crystal for system clock was too much to ask. It would miss some PWM cycles, especially while tring to sync changes to dutycycle/etc.

[techstudio-design]

Hmm, I'm sure that for DB (and the new ATtiny series 2) there are some significant improvement in design and manufacturing process. I noticed that for Series 1 and 0, there are more part numbers than the newer chips that coming out in the past year or so. For example, for ATtiny3217(from section 18.1 of ATtinty3216/3217 Datasheet), certain parts are not support (or rather Microchip won't guaranteed) to operate at 20MHz or 1.8v.

Ordering Code(1)	Flash/SRAM	Pin Count	Max. CPU Speed	Supply Voltage	Package Type(2,3)	Temperature Range
ATtiny3216-SNR	32 KB/2 KB	20	20 MHz	1.8V to 5.5V	SOIC	-40°C to +105°C
ATtiny3216-SN	32 KB/2 KB	20	20 MHz	1.8V to 5.5V	SOIC	-40°C to +105°C
ATtiny3216-SFR	32 KB/2 KB	20	16 MHz	2.7V to 5.5V	SOIC	-40°C to +125°C
ATtiny3216-SF	32 KB/2 KB	20	16 MHz	2.7V to 5.5V	SOIC	-40°C to +125°C
ATtiny3217-MNR	32 KB/2 KB	24	20 MHz	1.8V to 5.5V	VQFN	-40°C to +105°C
ATtiny3217-MN	32 KB/2 KB	24	20 MHz	1.8V to 5.5V	VQFN	-40°C to +105°C
ATtiny3217-MFR	32 KB/2 KB	24	16 MHz	2.7V to 5.5V	VQFN	-40°C to +125°C
ATtiny3217-MF	32 KB/2 KB	24	16 MHz	2.7V to 5.5V	VQFN	-40°C to +125°C

[SpenceKonde]

Yeah the extended temp range tiies are 2.7-5.5 volts. Between 2.7V and 4.5 their spec'ed maximum speed increases approximately linearly.

But that's to be expected. There's a HUGE difference between Dx and tinyAVR on this sort of thing. The Dx has an internal regulator that supplies the core, which is, the Vcore is somewhere in the area of 1.8-1.9v (supporting evidence: Minimum MVIO voltage is like 1.6x, and the "if voltage drops to 1.8 and then recovers, then the power usage goes up unless the voltage gets above 2:.1V.Sounds like that's where it switches between an internal regulator an being directly powered for by Vdd? You can see from what's available. even 48 MHz isn't on a 1.8v part is nothing special these days right? One consequence of the lower VCore? If you ramp the voltage up crazy fast (like, just the 0.1uf caps originally spec'ed in datasheet, in maybe a USB thumb drive shaped package, and you stick it into a USB port, located right on the motherboard of a laptop, which ties it to the 5v rail and all of it's capacitance, wires are like an inch or two in total (low inductance), that would lead to the regulator overshooting and potentially damaging the chip. They have changed that section twice, first the 0.1uF's which he knew he needed (I'm sure the engineer involved at microchip had in his mind some sort of board level decoupling if a situation like this were to come into being), but the damned fool put no board level decoupling, and it apparently caused problems. So they switched to recommending 3x 1uF (that'd slow it down enough, you know?) and now they're recommending 3x 0.1uF again, plus optionally a 1uF.

For systems that frequently cycle VDD or experience fast VDD transients, it is recommended
to add an additional decoupling capacitor (C3) if the power supply slew rate exceeds the slew rate limits.
Refer to the Supply Voltage section in the Electrical Characteristics for details about power supply slew
rate limits.

I would expect them to be cranking out the previous generation faster, they've probably got production happening in mutlple locations, and by now they've got a huge order book for them so it's full speed ahead. Probably not making the 2-series in as many facilities yet - they're still pretty new, they're already in tons of things that are already in production - how many products can there be using the 3227 just a few months after release.

[SpenceKonde]

What I'd kill (okay, no, that wouldn't help - waterboard) for is the trick to tell if a Dx-series part or some of the new tinies that don't mark it on the package is whether the part is extended temp range without contacting microchip "support" which is staffed by people who need to be watered twice a week and whom I have no faith in.) If there isn't a marking on the chip, and there isn't a different byte in chip data (If there is it's not in the sigrow) then there's no way to know that they aren't cheating you,
Binning them by performance at temperature into a bunch of ranges, but varying the boundary between the two as supply and demand change, so you could get lucky and get low temp range from a bin that could be extended, or get fucked out of the sizable premium on the extended temp range parts by getting one from a bin that would not be extended except that their process isn't supplying enough E-spec parts.

And I very much care about extended temp range, because have applications that need a DB clocked at 32 MHz minimum likely 40 to meet performance targets and I would like to run those mofos at 48 MHz. (application has 91% of the cpu time spent in bitbanging mode, so I have 9% of the CPU time only to do generate 3000 bytes of output including up to 6 random numbers - which I have to write my own RNG for because the piece of shit arduino ships with for a random function contains a 32-bit division operation in it, whole thing takes 700 clock cycles whether you need 4 bits or 32). I was not even able to meet 5% of the target with a 328pb at 16, and E-spec overclocks better. A part that runs at 24 MHz at 125C is more likely to run at 40 at room temperature than one that only wors at 24 MHz and 105C.

[tlyu]

In case it's helpful, here are some dumps from a batch of ATmega328P-PU chips (all from one DigiKey order a while back). This seems to match the documented AVR signature serial number format for ATmega328PB, among others.

Note that bytes 0x0E through 0x13 are the byte-swapped lot code from the reverse (2U2778). Likewise, 0x15 through 0x17 are plausibly the wafer number and X-Y coordinates, given that the bytes in position 0x15 don't seem to vary much.

Bytes 0x7E and 0x7F aren't likely to be a checksum, given their small amount of variation.

Chip top date codes are all 1220.

Chip reverse markings are all:

2U2778
35473D
1-P1220 e3

1E9B95FF0FD6FF26FF08FF17FFFF5532
37323837FF180D0C170112051305FFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFF0F8B
5858BE66CA93774A1775FD14C00B7214
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFE30A

1EA295FF0FE4FF26FF0BFF17FFFF5532
37323837FF16231B170112051305FFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFAB8A
3658EB668C92544AFB784315D30CD914
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFDB0A

1EAD95FF0FDDFF26FF0BFF17FFFF5532
37323837FF16211E170112051305FFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFEB8A
F6583B67CE93E14AA8756616350D9B16
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFCF0A

1EA895FF0FE1FF26FF0CFF17FFFF5532
37323837FF180E09170112051305FFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFF4889
E2576366A19199496C745C15ED0C8214
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFF610B

1EA595FF0FCBFF26FF0CFF17FFFF5532
37323837FF180E24170112051305FFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFF3E8A
7457FA64F990514895740117670C1617
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFF5D0B