Documentation:Things That Are Broken
From AVRFreaks Wiki
Contents |
[edit] Broken by Design
This section contains lists of known bugs that are not yet fixed, may never be fixed, or are fixed but you might not have the update.
[edit] Atmel AVR - Unofficial Errata
Device: CAN128
Summary: Miss-functioning when code stack is in XRAM
Errata Description: 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.
Device: TINY2313
Summary: Calibration byte location wrong in Datasheet
Errata Description: 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.
Problem Fix/Workaround: The corrected text is: 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.
Device: MEGA48/88/168
Summary: Example USART code in ASM wrong in Datasheet
Errata Description: 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.
Problem Fix/Workaround: Use LDS/STS/SBRS commands instead of the IN/OUT/SBIS commands listed in the datasheet example.
Device: AT90CAN128 (B, others not tested), MEGA32/48/88/168
Summary: Timer register updates cause lost interrupts in certain situations.
Errata Description: 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. If timer2 is used for for real time clock, and output capture is also used, the RTC may lose time.
Problem Fix/Workaround: Avoid writing to the timer2 registers when TCNT2 is 0xFF or 0x00 (or 0x01 if coming out of power save).
Device: MEGA8515
Summary: SPI programming glitches at programming speeds of FCPU/4 or more
Errata Description: 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.
Problem Fix/Workaround: Use a programming speed of LESS than FCPU/4.
Device: MEGA169, 8535
Summary: Using 32KHz 20ppm watch crystal, real time clock isn't precise (loose 1h/year).
Errata Description: Asyncronous timer driven by a watch crystal may glitch occasionally, causing inaccurate RTC values.
Problem Fix/Workaround: Contrary to what datasheet says, mount 10/22pF capacitors between the crystal pins and ground (loose 10min/year).
More unofficial errata may be viewed in the stickied forum thread:
[edit] Software Bugs
Tool: Avarice
Operating System: Windows
Summary: Standard Windows Com Port names will cause ioctl errors.
Details: Changes to Cygwin cause the standard com port names like "com1" to crash avarice. This standard naming convention worked in earlier versions. However later builds after 2004 will crash with a "JTAG ICE communication failed: Inappropriate ioctl for device" error when using this old syntax.
Workaround: Command strings to avarice must follow the com port naming convention that Cygwin understands. Cygwin support 16 com ports and these are "zero based" rather than "one based" like Windows.
for "com1" use "/dev/ttyS0"
for "com16" use "/dev/ttyS15"
(remove the quotes when using the above strings)
[edit] Broken by Users
Problems in this section are a manufactures favorite sort of problem. They are problems users create, and they don't have to solve because it's the users fault. But they can be easy traps to fall into sometimes, with the mention of the 'problem' on page 245 of the datasheet in one paragraph.
[edit] Clock Issues
If suddenly you cannot program your AVR anymore, you most likely have a clock issue. Many newer AVRs run on the internal RC oscillator by default, so as long as there is power there is a clock. You need a clock to program new code in your device, or change the fuse bits.
The fuse bits control many features of the AVR, including where it gets its clock from. Since by default you get the clock from the internal oscillator, as soon as you get the AVR it just needs power to program it. In many applications you want to use an external crystal however, and change the fuses to support this. If you program the fuses wrong, you will not be able to program the AVR again all of a sudden! It's probably not gone forever, but you should know some things first:
The AVR calls a programmed fuse a logic low ('0' level). Hence you program a fuse to 0, and erase it to 1. If using AVR Studio this is not an issue, as there is simple check boxes for 'external oscillator', 'crystal 8Mhz or above' etc.
Now the second problem: an external oscillator and external crystal are different things! An external oscillator means the AVR is expecting a logic-level oscillator signal. If you have a device which you apply VCC and GND to, and it has a output pin that you wire to XTAL1 on the AVR, that is an external oscillator. A crystal or resonator on the other hand has two or three pins, might need some external capacitors, and goes between the XTAL1 and XTAL2 pins.
If you just changed the fuses and the AVR stops, you probably have the AVR expecting something it will not get. Luckily in almost every case no matter what the fuses say you can apply a logic-level oscillator on the XTAL1 pin. The AVR will pick this up and use it, allowing you to change the fuses to the correct type.
TODO: Explain how to get this oscillator from different sources (other AVR's, etc)
[edit] Mega128 Programming
Note the AtMega128 chip does NOT use the marked MISO/MOSI pins for programming. Check the datasheet under "SPI Serial Programming Pin Mapping" to discover you should use the following for programming:
| Programming Line | Pin |
|---|---|
| MOSI | PE0 |
| MISO | PE1 |
| SCK | PB1 |
As this is apparently an inheritance of the venerable ATmega103 (which the ATmega128 is a designated replacement for), this used to be the same on the ATmega103 already. Likewise, it's still the same for other TQFP-64-compatible ATmegas that are in the "upgrade path" of the ATmega128: the ATmega1281 and ATmega2561. In contrast, the 100-pin siblings of the latter devices are not affected by this, nor are the TQFP-64 ATmegas of the LCD line (ATmega165/ATmega169 and their upgrade parts), even though they are otherwise fairly pin-compatible to the ATmega128.
[edit] Custom Butterfly Application Suffers from "Spurious Resets"
When starting a custom application for the AVR Butterfly via the bootloader, the butterfly application and/or the bootloader leaves the pin change interrupts enabled. If the application doesn't implement an interrupt handler for that, it will perform the default action for unassigned interrupts which is a restart from address 0 for avr-libc.
Solution: if you don't need the pin-change interrupt, set EIMSK to 0. An application that has been started from the butterfly bootloader cannot rely on the hardware state being pristine as an application started by a normal hardware reset could do.
[edit] Other Links
http://www.ladyada.net/resources/ucannoyances.html Outside website with other issues
