AVR Errata - Unpublished, and other "Gotchas"

Go To Last Post
70 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

This thread will be a listing of all known bugs in AVR devices that is not yet published. If you have received a message from Atmel saying the problem is an actual bug/errata but is not yet published in the datasheet, post it here.

This is NOT the thread to ask questions in, start a new thread if you are unsure if your problem is a real bug or better yet e-mail avr@atmel.com

-MMC

Last Edited: Sat. May 21, 2005 - 01:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Originally posted by hwmaier at http://www.avrfreaks.net/index.p... :

Device: ATCAN128

Summary: Miss-functioning when code stack is in XRAM

Hello fellow AT90CAN128 users and AT90CAN128 users-to-be,

in another thread I am discussing issues relating to AT90CAN128, XRAM, and interrupts (Refer to http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=149106#149106)

This issue has now be confirmed by Atmel in an email to be a bug in the silicon which limits the use of AT90CAN128 with SP pointing to XRAM.

As this unpublished silicon bug has cost me lots of time and money, I think it should be published before the next datasheet revision is released to save other users from the same experience.

Quote:
Hello Mr ...,

I confirm the bug on our Product AT90CAN128.
The following description will be added in the next version of the
datasheet.
-------------------------------------------
Miss-functioning when code stack is in XRAM
If either an "IN" or an "OUT" instruction is executed just before an
interrupt occurs and if the stack pointer (SP) targets the XRAM, the
instruction is
executed twice. Because the other instructions are not from the same
class,
it seems that only "IN" and "OUT" instructions are concerned.

Problem Fix/Workaround
Map the code stack in SRAM.
-------------------------------------------
We confirm that the only workaround is to map the stack in the internal
RAM.

The Design correction will be done as soon as possible.

...
Technical Marketing
Atmel - Nantes - France

Last Edited: Sat. May 21, 2005 - 01:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Originally posted by gskinner at http://www.avrfreaks.net/index.p... :

Device: ATtiny2313

Summary: Calibration byte location wrong in Datasheet

thought I would cross post this now that Atmel has told me what is wrong

as stated by atmel rep (regarding osccal bytes in tin2313):

The problem here is actually a typo in the datasheet:

The ATtiny2313 stores two different calibration values for the internal RC
Oscillator. These bytes resides in the high byte of address 0x0000 and
0x0001 in the signature address space for 4 and 8 MHz respectively.

The correct would be:

The ATtiny2313 stores two different calibration values for the internal RC
Oscillator. These bytes resides in the high byte of address 0x0000 and
0x0001 in the signature address space for 8 and 4 MHz respectively.

The old 4.10 version of AVRStudio read correct (but actually wrong
according to the datasheet). In 4.11 it was changed according to the
datasheet, but this introduced the error reading the wrong byte.

Update July 6, 2005

There is a fix for AVR Studio SP3, see http://www.avrfreaks.net/index.p...

In future versions of AVRStudio hopefully this is fixed.

Last Edited: Wed. Jul 6, 2005 - 10:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Device: AtMega48/88/168

Summary: Example USART code in ASM wrong in Datasheet

The example USART code in the Mega88 datasheet uses the commands in/out/sbis to access the UDR0 and UCSR0A registers. However they are outside of the dataspace accessible by this type of command, so you need to use lds/sts/sbrs

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

Just a reply to make the new post go off - the Tiny2313 was updated to include a fix for AVRStudio.

-MMC

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

Device: AT90CAN128 (B, others not tested)
Summary: If TCCR2A or OCR2A is written in the time window between TCNT2 rolling over to 0x00, and one tosc1 cycle later, the overflow flag will be lost and no interrupt generated.
Implications: If timer2 is used for for real time clock, and output capture is also used, the rtc may lose time.
Workaround: Avoid writing to the timer2 registers when TCNT2 is 0xFF or 0x00 (or 0x01 if coming out of power save).

Quote:
Dear Mr. Kaspar Pedersen

I have tried your code, and I found the same ting as you. We don't know any
workaround except the one you are suggesting: - to avoid the situation. It
seems that you have done a good job testing the behaviour of the device.
Thanks. The matter will be reported internally.

From the device marking that you wrote in your mail the device is rev B.

Best Regards
Marius Leine With
Atmel AVR Technical Support


Grr. They spelled my name incorrectly. Test code attached.

Edit: Same behaviour observed on ATMega32 (rev B), but not confirmed from Atmel on this part.

Edit: received 8/8 2005:

Quote:
We confirm that we have a bug on this function and writing to any of
tcnt2, tccr2 or tocr2 will clear the flags in t2 async register, tov2
and ocf2, regardless of any pending event that would set the flags
(capture or roll-over).

Workaround : do not write to any of tcnt2, tccr2 or tocr2 will clear the
flags in t2 async register, tov2 and ocf2 when the Timer2 is running.

We are working on a correction on the chip.

Attachment(s): 

Last Edited: Mon. Aug 8, 2005 - 11:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here a correspondence between ATmel and I regarding the SPI on an ATmega8515, its two emails that I have spliced together and removed names, hopefully this will save some people some headaches:

Quote:

> Problem : Issue with SPI on ATmega8515 MCUs Details : I would like to
> know what the fix time frame is on the SPI for the ATmega I am aware
> of a sampling issue relating to this interface resulting in an
> observed error rate of 1 byte per 1000 operating the SPI serial clock
> at 2MHz (8 MHz system clock). I wanted to know if this issue has been
> addressed yet and if not when?
this is not considered an issue and will probably never get a "fix".
The best fix so far is to simply slow down the SPI communication.
But I must agree that at least; an errat should have been provided.

some more info on this matter:

With SPI configured as slave, CPOL=0 and CPHA=1, the data will be sampled two internal clock cycles after falling edge of the SCK. With a SCK frequency at 1/4 of the internal clock, data will be sampled at the next rising edge, where also next data are being set up. This is obviously not a lucky setting.

SCK should therefore be LESS than 1/4 of the main clock frequency.

If you wish to do this in hardware, you should delay the MOSI data with two slave CPU clock cycles. If you are running the slave at 8.912Mhz, two cycles delay will be ~224.4nS.

A possible software work around could be setting both CPOL and CPHA = 0 for the slave.
This means that the slave should sample on the rising edge, but due to the delay it will in fact sample on the falling edge. You can see this if you look at figure 62 and 63 in page 132 of the data sheet. If the master operates with CPHA = 1 and the slave operates at CPHA = 0, the slave should sample on the next falling edge just like the master because of the two cycle delay. If you have a board you can test this on, this should be fast to try.

Please notice that we have not tested any of this here, and the results are only observed in simulations.

Best regards,

***************
AVR applications group

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

Device: ATmega48/88/168

Problem: Timer2 async mode overflow interrupts can be missed

If timer 2 is running in async mode (e.g. using a 32768Hz watch crystal), and overflow interrupts are enabled, the overflow interrupt will be missed if any of the timer registers are busy after writing during the async clock cycle (i.e. about 31 microseconds) following the overflow of the counter from FF to 00.

This can be made to happen reliably by creating an interrupt on one of the timer 2 compare registers, with that compare register set to FF, and writing to TCCR2A, TCCR2B, OCR2A or OCR2B in the interrupt routine.However it will also happen intermittently if any of the timer registers are written from non-interrupt code which happens to execute just as the timer overflows.

Work-around: (1) Don't write to timer 2 registers in non-interrupt code when overflow interrupts are enabled, unless precautions are taken to make sure the counter does not contain FF or 00. (2) Timer 2 registers may be written in timer 2 compare interrupts routines provided that the compare register is not FF; if the compare register is FF, delay at least 1 clock cycle (e.g. over 31 microseconds) before writing any timer registers.

(Edit, 2005-11-13: Looks like the same problem reported by KKP for different chips on 2005-06-21. Maybe this applies to all chips with async timers.)

Last Edited: Tue. Feb 21, 2006 - 08:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Device: ATMega169, 8535 + probably other devices

Problem: using 32KHz 20ppm watch crystal, real time clock isn't precise (loose 1h/year)

Work-around: contrary to what datasheet says, mount 10/22pF capacitors between the crystal pins and ground (loose 10min/year)

I found this work-around in the "Atmel Journal n1 Summer 2003", Brian Millier's article:
.........
I chose to implement the real-time clock in the software. One reason I initially
picked the ’8535 over the slightly less expensive ’8515 is because it
includes a third timer, which may be driven by a 32,768-Hz watch crystal. I
must say that my attempts to implement the RTC using this feature gave me
some problems! Atmel’s datasheet for the ’8535 advises you to merely connect
the 32,768-Hz watch crystal between the TOSC pins 1 and 2 with no
capacitors to ground. [1]
When I did this, I could see a reasonable 32,768-Hz sine wave signal on either
crystal pin with my oscilloscope using a 10x probe. I soon discovered, though,
that my clock was losing about 1 min./h. After troubleshooting, I found that
the crystal oscillator waveform contained serious glitches coinciding with LCD
screen refreshes.
At that point, I was using the port pin adjacent to TOSC1 to drive the LCD
ENABLE pin. Moving the LCD ENABLE pin over to port A eliminated the glitches,
but the clock was still slow. This was odd because I could not see anything
wrong with the crystal waveform with my oscilloscope, and the built-in frequency
counter in the oscilloscope indicated that the frequency was “bang-on.”
So next, I contacted Mark at MCS Electronics to see if he had run into the problem.
He mentioned capacitors, which made me think that capacitance to
ground was probably needed (contrary to the datasheet). It turns out that my
oscilloscope was providing the necessary capacitance, but only when it was
hooked up. Adding 22-pF capacitors to ground cured the problem, at least with
the particular crystal I was using. However, for this project, I decided to play it
safe and implement the RTC using Timer0 of the ’8535 clocked by the
4.194304-MHz crystal of the CPU, which works perfectly. A side effect of this
was that I couldn’t use BASCOM’s intrinsic real-time clock function and instead
had to write my own routine.
..........

Patrik

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

Rotamat wrote:
Device: ATMega169, 8535 + probably other devices

Problem: using 32KHz 20ppm watch crystal, real time clock isn't precise (loose 1h/year)

Work-around: contrary to what datasheet says, mount 10/22pF capacitors between the crystal pins and ground (loose 10min/year)


This seems to be a common error in AVR datasheets. The Mega48/88/168 real-time clock runs very fast if you just connect a 32K crystal without capacitors. Connecting caps in the 10-15pF range (depending on the crystal spec) seems to improve things.

Here is some earlier advice I received from Atlmel:-

avr@atmel.com wrote:
I know that you are a www.avrfreaks.net user so you have propably already seen the "Why you need a clocksource" article in the Academy section. On the page dealing with crystal oscillators there are some simple maths. To calculate the exact/optimal caps for the crystal you choose you need the stray capacitance from the part and from your PCB. The part stray capacitance has two components the die capacitance which is 3-5pF and the package capacitance which is 3,8pF for the mega168 in TQFP packages. The capacitance from the PCB can be ignored (or approximated to something like 1pF) if you follow the design hints from application note AVR042 available from www.atmel.com/avr --> Application notes.

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

Device: ATtiny25/45/85
Summary: Error in pin assignments for ACD inputs.

Table 19-4 on page 137 of the ATtiny25/45/85 Preliminary Complete (Revision C) data sheet shows (in several places) that ADC2 is on PB3, and ADC3 is on PB4. The port bit assignments are reversed.

That is, in all cases in the table ADC2 (PB3) should be replaced with ADC2 (PB4) and ADC3 (PB4) should be replaced with ADC3 (PB3).

Pin assignments are shown correctly elsewhere in the data sheet.

Edit: Has been corrected (as of Rev D?).

Regards,
Steve A.

The Board helps those that help themselves.

Last Edited: Sun. May 7, 2006 - 07:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Device: ATmega164/324/644
Document: datasheet doc2593.pdf
Errors:
1. Power-down Mode description is wrong, see page 38: ATmega164/324/644 has three sources of external pin interrupts only!
2. Serial Programming Pin Mapping is wrong, see page 290.

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

Device AT90PWMx
Document doc4317.pdf (rev E 02/06)
Summary Serial downloading page write commands wrong

The paged write commands for serial downloading to the AT90PWMx
device erroneously specify bits 0 through 5 for the address inside
the page, and bits 6 through 11 for the page address in table 58.
However, these devices do have 32-word pages (address bits 0
through 4), so the page load and write commands need to be
adjusted accordingly.

AVRDUDE 5.1 thus uses the wrong page write command, so
any flash write operation through bit-bang programming adapters
writes garbage.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

ATMEL has several data sheets with problems in the program examples on how to use IVCE in the MCUCR register. Only the newer AVR microprocessors where JTD was moved into the MCUCR register, that also has the IVCE and IVSEL bits, have this problem. Both JTD and IVCE are 4 cycle timed operations.

The problem is the data sheet IVCE example program for moving the interrupt vector will also clear the JTD bit, which has the hidden surprise of enabling the JTD bit when you thought you were only moving the interrupt vector (JTD is active when cleared).

These eleven data sheets have correct examples that do not overwrite and enable JTD when using IVCE and IVSEL:
Page 64 AT90CAN128 – 4350G-CAN-09/05
Page 59 ATmega165P – 8019B-AVR-04/06
Page 60 ATmega169P – 8018B-AVR-04/06
Page 52 ATmega325/3250/645/6450 – 2570G-AVR-04/06
Page 53 ATmega329/3290/649/6490 – 2552E-AVR-04/06
Page 74 ATmega640/1280/1281/2560/2561 – 2549J-AVR-09/06
Page 58 ATmega325P/3250P - 8023A–AVR–12/06
Page 58 ATmega329P/3290P - 8021A–AVR–12/06
Page 59 ATmega644 - 2593M-AVR-08/07
Page 66 ATmega164P/324P/644P - 2593M-AVR-08/07
Page 65 AT90USB64/128 - 7593F–AVR–02/08 FIXED :)

Be aware the new Pico power chips added a new BODSE 4 cycle timed operation bit to the MCUCR register. These chips have three different JTD, BODSE and IVCE cycle timed operation bits in the same MCUCR register. Use care when changing any of them, so you do not accidentally change another one you did not want changed.

I know the following data sheets program examples are not correct:
Page 50 ATmega165 – 2573B-AVR-03/05 –and– Page 50 ATmega165 – 2573D-AVR-03/06 –and– Page 50 ATmega165 – 2573F-AVR-08/06
Page 50 ATmega169 – 2597A-AVR-05/05 –and– Page 50 ATmega169 – 2514O-AVR-03/06 –and– Page 50 ATmega169 – 2514P-AVR-07/06
Page 53 ATmega406 – 2548D-AVR-06/05 –and– Page 54 ATmega406 – 2548E-AVR-07/06
Page 63 AT90USB82/162 - 7707A-AVR-01/07 Brand new data sheet, SAME OLD BUG :? , Page 66 7707B-AVR-11/07 –and– 7707C–AVR–12/07 STILL SAME OLD BUG :?
Page 66 ATmega164P/324P/644P automotive - 7674A–AVR–04/07 - 7674B–AVR–01/08 STILL, SAME OLD BUG :?

Sadly, this incorrect information is STILL being perpetuated in new data sheet releases (see above).

This is not a problem with any of the debugWire chips because they do not have a JTD bit.
______

Jim ka7ehk noticed some other data sheet problems. In the following data sheets the old MCUCSR name was incorrectly used instead of the new MCUCR name when the JTD bit or JTAG is described. Then he found some MCUSR names that should be MCUCSR. I also found a few CLK0 (digit 0) typos that should have been CLKO (letter O).

ATmega164P/324P/644P automotive - 7674A–AVR–04/07 (1-MCUCSR) Brand new data sheet, SAME OLD TYPO :?
ATmega164P/324P/644P – 8011C-AVR-10/06 (1-MCUCSR) - 8011E-AVR-04/07 8011G–AVR–08/07 - NEWER 8011H–AVR–04/08 TYPO STILL NOT FIXED :?
ATmega165 – 2573F-AVR-08/06 (4-MCUCSR)
ATmega165P – 8019H-AVR-11/06 (4-MCUCSR) NEW 8019I–AVR–08/07 - TYPO NOT FIXED :?
ATmega169 – 2514P-AVR-07/06 (4-MCUCSR)
ATmega169P – 8018I-AVR-11/06 (4-MCUCSR) NEW 8018J–AVR–08/07 - TYPO NOT FIXED :?
ATmega325/3250/645/6450 – 2570J-AVR-11/06 (4-MCUCSR) NEW 2570K-AVR-04/07 - TYPO NOT FIXED :?
ATmega329/3290/649/6490 – 2552H-AVR-11/06 (4-MCUCSR) NEW 2552I-AVR-04/07 - TYPO NOT FIXED :?
ATmega640/1280/1281/2560/2561 – 2549J-AVR-09/06 (1-CLK0) - 2549K-AVR-01/07 NEW 2549L-AVR-08/07 - TYPO STILL NOT FIXED :?
ATmega644 – 2593J-AVR-09/06 (1-MCUCSR) NEW 2593M–AVR–08/07 - TYPO NOT FIXED :?
ATmega406 – 2548E-AVR-07/06 (1-MCUCSR)
AT90USB82/162 – 7707A–AVR–03/07 (2-CLK0) Brand new data sheet :?

ATmega16 – 2466N-AVR-10/06 (1-MCUSR) NEW 2466O-AVR-03/07 - TYPO NOT FIXED :?
ATmage162 – 2513H-AVR-04/06 (1-MCUSR) NEW 2513I–AVR–02/07 - TYPO NOT FIXED :?
ATmega32 – 2503J-AVR-10/06 (1-MCUSR)
ATmega323 – 1457G-AVR-09/03 (2-MCUSR)
ATmega64 – 2490L-AVR-10/06 (1-MCUSR)

Page 65 AT90USB64/128 - 7593F–AVR–02/08 1-MCUCSR and 3-CLK0 typos FIXED :) This is the first one of these typos I have seen fixed.

The ones that have MCUCSR indicated should be MCUCR. The ones with MCUSR indicated should be MCUCSR. The ones with CLK0 (that is CLK-digit zero) should be CLKO (CLK-letter O). The number is the number of times I found the error in the same data sheet. MCUSR is only used in the newer chips. MCUCSR is only used in the older chips.
______

Any AVR with a TWI module:
TWI formula error: This (1/Fscl-2/Fck) formula appears in many data sheets Electrical Characteristics section, Two-wire Serial Interface Characteristics in notes 6 and 7. The formula is supposed to be (1/2*Fscl-2/Fck). The Tlow time period calculations work correctly with the new formula.

For note 6:

ATMEL support wrote:
Fck=6 MHz gives 4.67uS
Fck=7 MHz gives 4.71uS
So the idea was that Fck needed to be higher than 6MHz (or close to 7MHz) to meet these requirements.

BTW, newer versions of some of the above data sheets have already been released and the above errors have still not been fixed. The errors were reported to ATMEL and acknowledged as data sheet errors, but have never been dealt with. I fully intend to remove the above data sheet error information when (if) the data sheets actually get fixed. The initial JTD program example error was first acknowledged by ATMEL on March 10, 2005, has been re-reported and is now over 3 years old and counting :shock:. Now brand new data sheets have copied this same bug again :?. However, three problems reported in the Attiny24/44/84 data sheet were fixed in less than two weeks. I do not understand what is going wrong at ATMEL, but something very important is badly broken.
______

Attiny24/44/48 Automotive - 7701A-AVR-05/07 Data Sheet:
Page 137 section 17.2.3 DIDR0 – Digital Input Disable Register 0: should be ADC2D, ADC1D.
ADC0D is not an Analog Comparator pin.

These three errors were already fixed in the Attiny24/44/84 - 8006F-AVR-02/07 Data Sheet, but reappeared in the Attiny24/44/48 Automotive - 7701A-AVR-05/07 data sheet :?
1) The obsolete WDTCR name is used on the page 48 program examples. WDTCSR is now the correct name.
2) Section 4.11.9 (page 119) there is a typo in the TIFR1 register bit description. “ICIF1” appears in the drawing instead of “ICF1”.
3) The Read only (R) bit of the ACSR register ACO bit is incorrectly marked Read/Write (RW).
______
In 7679F–CAN–11/07 and 7679G–CAN–03/08 AT90CAN128/64/32 data sheets page 252 section 19.10.1 CAN General Control Register - CANGCON bit 6 OVRQ, "OVFG" should be "OVRG" in the explanation.
______

ATMEL support wrote:
Comment regarding questions about ATmega164P/324P/644P and mega644: in all sleep modes other than idle, INT2:0 covers level detected interrupt (low level int.) while PCINT31:0 when enabled, detects any edge.
The data sheet incorrectly claims the edge interrupt on INT2:0 are detected asynchronously, when they are really detected synchronously and cannot be used for wake up from sleep when CLKio is not running.

Table 12-14. Overriding Signals for Alternate Functions in PD3:PD0, still has an incorrect note. Note 1 should appear in Table 12-11. Overriding Signals for Alternate Functions in PC3:PC0. This note should also reference PC0/PC1 and not PD0/PD1.
______

Attiny2313/V data sheet 2543I–AVR–04/06 page 34 Table 14 Note 2: should be INT0 and INT1.
______

ATtiny26 data sheet 1477I-AVR-10/06 table 19 on page 40, Note 2 should be “for INT0, only level interrupt”.

Last Edited: Sat. Apr 12, 2008 - 04:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Device: ATmega48/88/168

Problem: PWM in "Phase Correct" or "Phase and Frequency Correct" mode, table 14.3 - p. 131 in Rev.G of doc. 2545 (datasheet 06/06) resp. p. 129 in previous doc. 2545 Rev. F - is supposed to be able to:

Quote:

WGM13:0 = 8, 9, 10 or 11: Toggle OC1A on Compare
Match, OC1B disconnected (normal port operation).
For all other WGM1 settings, normal port operation,
OC1A/OC1B disconnected.

(COM1A1/COM1B1 = 0, COM1A0/COM1B0 =1; second option in table)

This toggle option does not work, applying the flag pattern just disables the PWM functionality.

Note: Same may apply to corresponding option for "Fast PWM" mode, table 14-2 on previous page in datasheet - didn't check this explicitely).

[Addendum 17-JUL-2006]:

Quote:

I've tested and find this:

OC1A pin with COM1A1..0 = 01 (those modes covered by 14-3 (phase correct + phase and frequency correct)):

WGM13..0 = 1 : normal operation
WGM13..0 = 2 : normal operation
WGM13..0 = 3 : normal operation

WGM13..0 = 8 : dead
WGM13..0 = 9 : toggle on compare match
WGM13..0 = 10 : dead
WGM13..0 = 11 : toggle on compare match

[...]

The designers have verified that the device does not operate as described in the datasheet. We'll look into fixing this, either in the device or the preliminary datasheet.

As the non functional mode is covered by other settings, I see no reason why it needs to fixed in the hardware (as long as the datasheets reflect the
actual operation).

Jan Håvard Ugelstad,
Atmel AVR Technical Support

Addendum 26-July-2006:

Quote:
Mr. ...,

A short update, we'll update the datasheet(s) according to this:

In the datasheet under 16-bit timer/Register description/TCCR1A the table "Compare output mode, phase correct and phase and frequency correct PWM" for setting 01 the text "WGM13:0=8,9,10 or 11" should be changed to "WGM13:0=9 or 11".

This is the case for all low voltage mega parts with this text in the datasheet.

Jan H

Andreas

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

I found a minor mistake in the data sheet for the mega 329/649. Atmel doc2552.pdf. The address for PORTA is wrong.

Attachment(s): 

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

In the datasheet of ATmega644 on page 284 it is written: "The ATmega644 has four Fuse bytes".
This is ERROR!
Response from Atmel:
---------
The ATmega644p has three fuse bytes only. I will report the mistake in the datasheet.
Dag Vegar Tveitaa
Atmel AVR Technical Support
----------

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

I found a bug in the datasheet for the atmega329p. The description of the EIMSK register shows the wrong location. Should I send an e-mail to avr@atmel.com?

By the way, the Add Attachment button wouldn't add the attachment so I did it the old fashioned way.

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

In the ATmega48 manual (2545-AVR-09/07) on page 52 the follow code is commented as "Clear WDRF in MCUSR":

in   r16, MCUSR 
andi r16,(0xff & (0<<WDRF)) 
out  MCUSR, r16 

It should be:

... 
andi r16, ~(1<<WDRF) 
... 

...or similar which only clears the specified bit.

The Atmel AVR doc team have confirmed this and it will be changed in new reveisions of this and other docs.

Nicko

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

The AVR096 application note should not show the clock select fuses (CKSEL3..0) as being the same as the Mega128, as the functions of the bits have changed.

In particular, anyone who has set CKSEL 3..0 to 1011 (correct on the Mega128 for a high speed crystal) will find these settings on the CAN128 appear to work but the crystal is driven very weakly and can be disturbed by noise, particularly from the adjacent SCL pin if the tracks are close. The correct setting for the CAN128 is 1111.

See my thread http://www.avrfreaks.net/index.p... for details of a case where this gave problems.

Last Edited: Wed. Apr 2, 2008 - 08:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The version 4 RC oscillator as it can be found on many modern AVRs
can experience much more clock jitter than previous versions. See
Atmel's explanation here.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Atmel have confirmed a typo in the data Sheet regarding stack usage on the ATMega166p/324p/644p (doc8011-AVR-04/08)

Atmel wrote:
Two bytes are pushed on the stack during a CALL instruction for ATmega164P/324P/644P. There is a typo in the ATmega164P/324P/644P datasheet. I've reported this and it should be corrected to the next release of the datasheet. Thanks for your observation, and sorry for any inconvenience.

The data sheet currently says three bytes.

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

The latest version of the AVR Instruction Set Reference (Rev. 0856F–AVR–05/08) Has a section marked "SPM #2" That shows an additional form of SPM. The shown opcode for forms i-iii ("SPM") cannot be correct as it conflicts with "BCLR 4" (also known as "CLS")

[Issue Corrected in: Rev. 0856G–AVR–07/08]

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Tue. Jul 29, 2008 - 08:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Devices: ATmega164P/324P/644P (doc8011), ATmega644 (doc2593), ATmega640

Data sheets erroneously include references to instruction ELPM and register RAMPZ.

Part description .xml files and definition .def files erroneously include references to RAMPZ.

Details in AVR studio 4 forum Post under topic "Assembler Errors."

Stan

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

Device: ATxmega128A1
Function: Flash Range CRC

The Flash Range CRC is unimplemented in silicon up until (and including) Rev H. It is intended for Rev J.

This is not documented in the datasheet.

See the following thread for details: http://www.avrfreaks.net/index.p...

It is, however, implemented in the ATxmega32A4.

Last Edited: Wed. Aug 5, 2009 - 09:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Device = ATxmega128A1, ATxmega32A4, probably others too.
Function = Hardware CRC

Bob Paddock in this thread http://www.avrfreaks.net/index.p... found that the CRC calculation in the XMEGA device manual is wrong and should be corrected:

Quote:

[/code]
/*
* The Xmega manual Rev G lists the CRC Polynomial
* as: x^24 + 4x3 + 3x +1.
*
* Based on some untested code supplied by avr(at)atmel.com,
* I believe the correct Polynomial is:
* x^19 + x^4 + x^3 + x^1 + 1
*
* At any rate after cleaning up their code issues, the following C
* code generates the same values as the XMega 128A1 hardware.
*
* Any math grues out there than can tells how
* strong this non-standard Polynomial is?
*
* The hardware initializes the CRC register to all zeros,
* rather than all ones. This can lead to missing the
* detection of inserted leading zeros.
*
* - Bob Paddock
*
*/
[/code]

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

The latest version of the AVR Instruction Set Reference (Rev.-0856H-AVR-07/09) Indicates additional cycle timings of 1 & 3 cycles for the LD family of instructions not present in previous editions. These new timings include a footnote. However, footnote fails to indicate this is for the new AVR8L (tiny10 and similar devices) core only. The key indicator in this note is the mention of being able to access program memory, which is not possible through these instructions on other AVR8 cores.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Greetings -

This is more of a heads-up, than anything.

I am setting up a Mega644P USART for 7-bit + parity transmission and reception. In section 18.8.1 of the 164p/324P/644P data sheet, it says:

Quote:
When using frames with less than eight bits the most significant bits of the data read from the UDRn will be masked to zero.

BUT... I was surprised to find the high bit set with some characters. Turns out, this bit is reported set when the parity bit is set in the received data. A closer rereading shows that it uses the term "frame" which could logically include the parity bit. I had initially interpreted "frame" to mean "data bits".

The solution is simple: just mask the received character with 0x7f.

Jim Wagner, ka7ehk

Original post: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=688049#688049
Copied here by Plons

A GIF is worth a thousend words   She is called Rosa, lives at Mint17.3 https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Filename: doc8077
Version: 8077H–AVR–12/09

Chapter: 7.14 Register Summary - DFLL32M/DFLL2M

The table contains two entries labeled "COMP2" on offsets 0x06 and 0x07.
The bit positions of the entry on offset 0x07 are the same as on offset 0x04 where label "COMP0" is described.

As Clawson indicated, the XML device description file is authoritative.

=================================================================================
C:\Program Files\Atmel\AVR Tools\Partdescriptionfiles>grep COMP2 ATxmega128A1.xml
                                        
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Filename: doc8077
Version: 8077H–AVR–12/09

Chapter: 7.13 Register Summary - Oscillator

The table does not name the bits 0 and 1 of the entry for DFLLCTRL.

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

Filename: doc8077
Version: 8077H–AVR–12/09

There are two graphical statements which locate the clock source for the watchdog in two different places.

In chapter 2.1 Block Diagram, Figure 2-1. shows a block named "Watchdog Oscillator" in the upper right corner.
(It is furthermore unclear what the connection to the clock generation depicts, resp. what kind of information or energy it transports).

Contrary to that, Figure 7-1. in chapter 7.2 shows that the watchdog timer is feed by the 32kHz ULP oscillator (divided by 32) which clocks the brown-out-detection too.

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

Filename: doc8077
Version: 8077H–AVR–12/09

Chapter: 7. System Clock and Clock options

While the description in 7.9.4 suggests that five clock sources may be selected for the RTC, the figure 7-1. in contrast does not depict the presence of the implied additional prescaler providing TOSC nor the necessary additional input for the multiplexer whose output feeds the real time clock.

Further the the figure 7-1 does not show any signal labeled "Clkasy"

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

Device: ATxmega32d4 32d4
GPIO Registers

Dear Customer,

ATxmega32D4 has only 4 GPIO registers. We will try to fix the document at the earliest possible.

Best Regards,
Anupama Sahayaraj
Atmel Technical Support Team

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

I have reported several errors on XMEGA datasheets and application notes to atmel:

Quote:
1- doc8077-page 71-Table 6.3:
Compare march -> Compare match
2- doc8077-page 72-Table 6.4:
101 CCxn_CCA -> 101 CCxn_CCB
3- doc8077-page 72-Table 6.4:
110 CCxn_CCA -> 110 CCxn_CCC
4- doc8077-page 72-Table 6.4:
111 CCxn_CCA -> 111 CCxn_CCD
5- doc8077-page 72-Table 6.3:
ClkPER divide by M (M=1 to 32768) -> ClkPER divide by 2^M (M=0 to 15)

Quote:
doc8046(AVR1304)-Revision B- page 5:
The transaction continues until one block is transferred even if repeat mode is enabled. When the block is transferred, the channel waits for the next trigger to arrive.
----------------------------------------------------------------------
doc8077-Revision H-page 51:
When repeat mode is enabled, the start of transfer of the next block does not
require a transfer trigger. It will start as soon as the previous block is done.
----------------------------------------------------------------------

AVR1304 indicates a trigger for every block of DMA, even if repeat mode is enabled. But it seems this is not the case in XMEGA A manual.


Quote:
In doc8041(AVR1302)-Revision B- figure 1-1, there is a multiplexer for applying pin inputs to voltage scaler.But according to XMEGA A manual, only Vcc is the input for scaler and I/O pins can not be applied to this voltage scaler.

Quote:
Several errors in XMEGA documents, shown in attached file (dac_0.pdf).

Quote:
2 errors in XMEGA documents, shown in attached file (DMA_0.pdf).

Quote:
1-doc8033(AVR1301)-Rev B-page 3:

"The event system could be used to maintain the required refresh rate, but in most cases, the event system is used to generate the sample rate instead."

But according to XMEGA A, there is no way for event system to be used for refresh of two channels in dual channel operation.

2-See attached file (DAC_1.pdf).


Quote:
I found some other errors in XMEGA A manual.In table 30.4-page 377, there are 2 columns:"CPU Halted" and "Change protected".
For the first column, all items are "N" and this is not correct. For second column, all items are "Y" and this is also not correct ( Load EEPROM Page Buffer is not Change protected).

Attachment(s): 

Ozhan KD
Knowledge is POWER

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

(I cannot attach more than 3 files to previous post).

Quote:
See attached file(AC_0.pdf).

Quote:
See attached file(SPI_0.pdf).

Attachment(s): 

Ozhan KD
Knowledge is POWER

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

Quote:
AVR1310-Rev B-page 3:

"The WDT is clocked from an internal 1kHz ultra low power (ULP) RC oscillator."

ULP RC oscillator frequency is 32khz and 1khz is obtained by /32 division.


Quote:
XMEGA A manual-Rev H-page 102:

"XMEGA has seven different reset sources."

But XMEGA has only six different reset sources.

Ozhan KD
Knowledge is POWER

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

The Mandarins at Atmel have made a serious error on Revision U of the ATmega128 datasheet. The diagram of Timer0 is different than the one from Revision S. of the same datasheet. TCCR0 now apparently allows clocking on rising and falling edges of pin T0. Problem is there is no pin T0 on an ATmega128.

Looks like some kind of cut and paste kerfuffle, and of course the real part does not match Revision U. of the datasheet.

I'm sticking with Revision S., Don't know about Rev T.

We never have time to do it right,
but we always have time to do it over

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

A GIF is worth a thousend words   She is called Rosa, lives at Mint17.3 https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

ATMEGA 164P/324P/644p:

Errors in the Serial Port innitialisation examples:
http://www.avrfreaks.net/index.p...

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

Update: Reported to Atmel, They say it should be fixed in the next datasheet revision

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

Quote:
In the ATmega48 manual (2545-AVR-09/07) on page 52 the follow code is commented as "Clear WDRF in MCUSR":
Code:
in r16, MCUSR
andi r16,(0xff & (0<<WDRF))
out MCUSR, r16

It should be:
Code:
...
andi r16, ~(1<<WDRF)
...

...or similar which only clears the specified bit.

Phew... 0 << (or >>) anything is just 0...

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

Device: ATtiny26

Summary: LD Rn,Z+ clobbers r31 (ZH)

On the ATtiny26, the LD Rn,Z+ instruction resets the high 8 bits of the Z register to 0. (According to the datasheet, it would either be unaffected or would be incremented on carry from r30/ZL).

The ATtiny261 does not have this bug, apparently.

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113437#887501

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

Filename: doc8271.pdf
Version: 8271D-AVR-05/11

Chapter: 18.11.2 TCCR2B – Timer/Counter Control Register B

WGM22 (bit 3) and CS22 (bit2) are marked R only but they are R/W bits

EDIT: this has been reported and acknowledged by Atmel.

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

For the ATtiny4313, datasheet and (AVR Studio 4.x) XML file disagree
in various ways about the presence or absence of the register SPH:

. the datasheet denies the presence of that register, both in the
verbose text as well as in the register summary;

. the XML file mentions the presence of SPH in the IO space, but the
respective bit in the IO read and write masks of the JTAGICE mkII
section still has that bit cleared, so the JTAG ICE won't access
SPH

Experiments with the JTAG ICE mkII in debugWIRE mode (using a fixed IO
bitmap in the device descriptor) indicate the device does have an SPH
register, actually.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

When operating several ATMega48/88/168/328 in SPI slave mode on one SPI bus, with different slave select lines going to each slave, all MISO lines are tied together.

The datasheet (current version 05/11 page 80, table 14-4) documents that MISO is controlled by the DDR bit when the SPI module is configured as slave. This would make it impossible (unwise) to configure the pin as output as the slaves might burn their drivers if they contend the signal level.

Once slave select goes active (low), you'd have to run a Pin change interrupt to quickly configure the pin as output, to allow the SPI module to clock the data out on the pin.

The above IS NOT THE CASE:

Page 162, bottom paragraph correctly states:

Quote:
When configured as a Slave, the SPI interface will remain sleeping with MISO tri-stated as long as the /SS pin is driven high.

A term "SPE . /MSTR . SS" should be / will be added to table 14-4.

Quote:
Yes you are correct. The information on the MISO pin getting tri-stated
when the SPI is configured as slave and when the SS pin being high is not
included under the I/O port section and it is better to have this
information in the I/O port section.

We have reported the concerned team about the issue to enhance the
datasheet accordingly.

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

ATtiny87 will not reset the watchdog when using an external clock. This is confirmed by Atmel as a silicon bug with no workround (see Atmel support response below). This will be revision C silicon and presumably applies to theAT tiny167 as well.

Hi Glyn,
yes I confirm that this is a bug and unfortunately I don't have a
workaround for it at the moment it will need to be fixed in the silicon.

You apparently cannot use the watchdog and clock switching at the same time
it is one or the other. For reference this Bug has been logged as Bugzilla
#6247.

Best Regards,
Robin Walsh
Atmel Technical Support Team

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

ATmega48A/PA/88A/PA/168A/PA/328/P
(567 pages, revision D, updated 5/11)

18. 8-bit Timer/Counter2 with PWM and Asynchronous Operation
- 18.11 Register Description
- Table 18-8. Waveform Generation Mode Bit Description

Shows the Waveform Generation Mode bits as "WGM2 WGM1 WGM0" when they
should be "WGM22 WGM21 WGM20".

Atmel acknowledgment:

Quote:

...snip...
Thanks for your interest in notifying us.

I have posted a bug in the datasheet and we may expect the fix at the earliest.

Sorry for the inconvenience and feel free to contact us in case of any other technical queries.
...snip...

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

I have an Xmega32a4u, silicon version 0x04. It seems the second DAC channel (channel 1) has not been calibrated in the factory. The two calibration values are 0xff in the Production Signature. These values give bad results. The first DAC channel (channel 0) has good calibration values.

I e-mailed Atmel and they suggested that using the calibration values for channel 0 should give good results on channel 1 also. I tried it and found it so.

Quote:
avr@atmel.com

Hi Steve,

I've verified this on a device here also. Only one channel have calibration values

The two DAC channels have very similar charactheristics and you can probably use the calibration value for channel 0 on channel 1 also, but I'll have to contact the persons responsible for the calibration routines to verify this and will get back to you with a final answer.

Best Regards,
Håvard Nygård
Atmel Technical Support Team

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

This is something I think is a bug, am not 100% sure. On the attiny861a (maybe other from the same family as well), I experience the following.

The datasheet explicitly mentions you can set bits in registers independently using or'ing and and'ing into the register. I've experienced that if you do that with the USI registers (USICR and USISR), strange things start to happen.

For example if you set the two twi-mode bits independently of each other, everything goes haywire. Another example, if you set bits in the same register where the bit shift counter resides, the bit shift register apparently gets mangled; the next overflow condition appears after only one bit of data, even though I selected 8 bits (= 16/0 edges).

I now write complete bytes into the registers (just like Don Blake's code does) and now it works.

I do believe that avr-gcc detects the usage of or's and and's on registers and compiles it into exactly one machine code instruction, so it should work with C as well, but you never know...

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

Device: ATMega2560
Debugger: JTAGICE3
IDE: AtmelStudio 6.0
Problem: TWI lockup

When communicating on the I2C (TWI), if there is ANY noise injected into your board, the TWI state machine can get hung up so that, for instance, setting a Start condition never fires the interrupt. Moreover, trapping the condition in the debugger and single-stepping through your code can (after the lockup has occurred) cause the entire AtmelStudio system to bomb.

A short time back, we were interfacing to a TWI-based magnetometer which worked flawlessly until we fired up some drive motors (a robotic system). Scoping the SDA and SCL lines revealed an occassional noise spike (on the order of 1V,20nS) caused by the motors. This was enough to throw the TWI system into a tizzy. It was not obvious how to reset the system, so I queried Atmel support.

The response from Atmel confirmed the susceptibility and recommended the method for recovering, which seems to work very well:

Quote:
Hello,

I have now heard back from our internal resources, and they suggested that this kind of issues can be caused by external noise or that the set-up and handling of TWI that is not optimal.

When reading status 0xf8, this means that the state is undefined and so the state machine handling TWI outputs a default status value 0xf8. If some noise injection is making the state machine enter an unknown state, it should normally be brought back to an idle state. Meaning the bus should be released, but noise could also lock the state machine in a unknown state. A way to bring the TWI into a known state is to toggle the TWEN bit in the TWCR register as you have done. This will reset the state machine and set it to a default idle state.

Also note that the data setup time has to be taken care of by software.
Always make sure there is enough time between updating TWDR and TWCR, and if not, insert "nop" in-between.
The data setup time is found in the Electrical Characterstics chapter in the datasheet.

Best Regards,
**************
Atmel Technical Support Team

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

There is a (very minor) typographical error in the datasheet for the ATtiny25/V / ATtiny45/V / ATtiny85/V.

On page 13, section 4.8.1 Interrupt Response Time, the following text appears:

Quote:
The vector is normally a jump to the interrupt routine, and this jump takes three clock cycles.
However the JMP instruction is not available in the ATtiny25/V/45V/85/V family. What is available is the RJMP relative jump instruction, which is sufficient to address all of FLASH in these devices.

A look at the vector table generated by avr-gcc shows that RJMP is indeed used:

#include 
#include 
int main(void) {
}
avr-gcc -mmcu=attiny85 foo.c -o foo.c.elf
avr-objdump -S foo.c.elf
foo.c.elf:     file format elf32-avr
Disassembly of section .text:
00000000 <__vectors>:
   0:    0e c0           rjmp    .+28         ; 0x1e <__ctors_end>
   2:    28 c0           rjmp    .+80         ; 0x54 <__bad_interrupt>
   4:    27 c0           rjmp    .+78         ; 0x54 <__bad_interrupt>
   6:    26 c0           rjmp    .+76         ; 0x54 <__bad_interrupt>
   8:    25 c0           rjmp    .+74         ; 0x54 <__bad_interrupt>
   a:    24 c0           rjmp    .+72         ; 0x54 <__bad_interrupt>
   c:    23 c0           rjmp    .+70         ; 0x54 <__bad_interrupt>
   e:    22 c0           rjmp    .+68         ; 0x54 <__bad_interrupt>
  10:    21 c0           rjmp    .+66         ; 0x54 <__bad_interrupt>
  12:    20 c0           rjmp    .+64         ; 0x54 <__bad_interrupt>
  14:    1f c0           rjmp    .+62         ; 0x54 <__bad_interrupt>
  16:    1e c0           rjmp    .+60         ; 0x54 <__bad_interrupt>
  18:    1d c0           rjmp    .+58         ; 0x54 <__bad_interrupt>
  1a:    1c c0           rjmp    .+56         ; 0x54 <__bad_interrupt>
  1c:    1b c0           rjmp    .+54         ; 0x54 <__bad_interrupt>
0000001e <__ctors_end>:

Note also that the size of each Interrupt Vector as described on page 47 of the datasheet, Table 9-1 Interrupt Vectors in ATtiny25/45/85 is indicated as 1 program word. This coincides with the size of an RJMP instruction (1 word), but not with that of a JMP instruction (2 words).

Atmel support has acknowledged this issue via email, and confirms that this error exists in the datasheets for many devices in the mega and tiny series. Likely a copy-and-paste error.

The correct text should be:

Quote:
The vector is normally a relative jump to the interrupt routine, and this jump takes two clock cycles.
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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

Pages