Byte 0x0E - 0x17 of SIGROW #1
Comments
|
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.
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): 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.... 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. 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. |
|
I'm aware that the code the link that I shared refer to the old 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 ATtiny3227 ATtiny3217 |
|
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: 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. |
|
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... |
|
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. |
|
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.
|
|
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 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. |
|
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, 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. |
|
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 Bytes Chip top date codes are all 1220. Chip reverse markings are all: |
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.
The text was updated successfully, but these errors were encountered: