SpenceKonde
commented
2 years ago 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.
- 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
tlyu
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.
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.