Mike B 
Moderator's note: this has been split off from a thread named just
"jtag" where the discussion simply went out of hand.
So, the missing AT90CAN128 is just an AVRstudio documentation mistake. Thanks for checking John.
Don't hold your breath waiting for the documentation to be fixed. ATMEL still has not fixed several data sheets with a +2 year old known program example bug. In fact they just put the same old bug into a brand new data sheet :roll:.
js 
they just put the same old bug into a brand new data sheet
> ATMEL still has not fixed several data sheets with a +2
> year old known program example bug.
Did you file an ATticket for that?
Mike B The first acknowledgment return e-mail from ATMEL was on March 10, 2005. The AT90CAN128 data sheet was quickly corrected, but it was the only one for quite a while. Over the years I have re-reported it when it kept appearing in new data sheets and had my reports re-acknowledged. The current count is 8 data sheets corrected, 7 data sheets have the bug.
In fact seeing this bug was still not corrected after almost the first year is why I originally posted to the AVR errata – unpublished sticky thread.
I think the era before they implemented their ticket system was prone
for someone to eventually forget about your mails. Now with the
ATtickets, they should in theory track it down until they can close
the ticket.
Mike B A December 12 2006, ticket based on the AVRfreaks errata thread as it appeared at that time has been closed. I was told:
I have forwarded your email to our team of technical writers(together with a link to the AVRfreaks thread). I have also added it to our datasheet bug tracking system. We have ensured that it is on out to-do-list for the next datasheet updates.
In another closed ticket that was answered on February 15 2007 where I made a point about the age of the bug, one of the ATMEL support people said they were going to follow up the case until it is solved. There has not been enough time since their reply to expect any results. In fact looking back I only brought all this up when discussing the other documentation error. I guess I'm feeling frustrated :).
I do not think the decision to close a ticket works exactly like you expect in your post. I have no problem at all with the ATMEL support people and the excellent support I have received over the years. I am forming the opinion that some of the data sheet maintainers do not appear to be connected to the “system” or something like that. Even data sheet changes that take large slow committees to approve should be faster than 2 years. Since some data sheets changed quickly, evidence suggests that if slow committees are at work here, different data sheets have very different committees.
Another example is even a straight forward simple typo logged in the December ticket was not corrected in the most recently changed ATmega162 data sheet.
Mike B An update. A new ATmega16 data sheet was just released that also ignored a simple typo correction. I am now starting to document all of the errors ATMEL refuses/cannot fix in the errata sticky thread.
Also, I just had a ticket closed that did not address all the issues I brought up. I pointed out the AT90CAN32/64/128 data sheet CAN 2.0 B extended frames drawings did not include the RTR bit in the arbitration field like the Bosch CAN specification does (the data sheet shows it in the control field). This is most likely a drawing typo. That aspect was never acknowledged or answered. The other issues were answered and the ticket was just closed is all. This is the first time the support people have screwed up when helping me.
My concern is as a designer/integrator/programmer using ATMEL parts, I find the data sheet information is critical. All this data sheet correction mishandling is starting to turn down my AVR enthusiasm.
theusch 
...starting to turn down my AVR enthusiasm...
Well, there is another survey running:
https://www.avrfreaks.net/modules.php...
As quoted in the AVRTV thread on the Off Topic Forum:
AVR microcontroller survey by Atmel
Posted by Eivind on Thursday, March 29, 2007AVR microcontroller survey by Atmel
Help Atmel improve the AVR® family of microcontrollers by answering a two-minute
survey at http://www.atmel.no/survey/
So if we all point out our favourite datasheet foibles, and also back to our sticky thread...
Lee
> An update. A new ATmega16 data sheet was just released that also
> ignored a simple typo correction. I am now starting to document all
> of the errors ATMEL refuses/cannot fix in the errata sticky thread.
I suggest moving that to the Wiki instead. I think it's simpler to
keep it up to date there (and to also mark/remove items that have
eventually been really fixed).
As for the ticket closed with only half the results, I'd try opening a
new one with the one issue that hasn't been resolved yet.
I agree with Lee, if there's enough voice, it might really change
things. After all, in the datasheet copy-protection issue, we've
eventually been overruling the legal department's opinion of a large
enterprise.
Mike B Thank you for all the information.
ATMEL has actually been updating some data sheets and application notes with no other change than just the document security features.
I think the Wiki is a good idea, except this sticky errata thread link has already been reported to ATMEL and acknowledged by them. I originally included the link as a reference for the support people, but they decided to pass it along with the corrections.
Mike B The story goes on.
A brand new 7674A-AVR-04/07 ATmega164P/324P/644P Automotive data sheet has the same bug and even preserved the typo from the original data sheet. Speaking of which, a new version 8011E-AVR-04/07 ATmega164P/324P/644P still has the same bug and typo.
A new version 2570K-AVR-04/07 ATmega325/3250/645/6450 and 2552I-AVR-04/07 Atmega329/3290/649/6490 data sheets preserved their typos.
Thats 4 data sheets today, zero correction of the reported problems.
Maybe we should start a betting pool. You will have to guess how many additional data sheets already in the errata sticky thread will be updated without any corrections of the reported errors. The other bet would be that none of them get corrected at least until after all of them have been updated or maybe never get corrected at all. Just kidding, I hope..... :).
Mike B Sorry about hijacking the original thread.
I have a new development. Twice now all I have gotten is a quick thank you, we will look into it. Then the tag is silently closed without confirming anything. Maybe they have figured out I will usually not add the data sheet bugs to the AVRfreaks sticky thread without acknowledgment that it really is an error :). So far the exception was the CAN frame drawing showing the RTR bit as part of the control field, that is obviously just wrong. Then again, maybe they are just overloaded and quicker to close tags?
That program example bug had its March 10, 2007 two year old birthday. I hope it was not a fun birthday party :(.
Mike B The brand new Attiny24/44/48 Automotive - 7701A-AVR-05/07 data sheet includes three errors that were already corrected three months ago in the Attiny24/44/84 - 8006F-AVR-02/07 data sheet.
https://www.avrfreaks.net/index.p...
Currently there is no sign at all of the data sheet correction problems getting any better.
Mike B On the other hand, Wow! A reported page numbering problem with the AT90CAN32/64/128 data sheet PDF was taken care of almost instantly.
