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
Originally posted by hwmaier at https://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 https://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.
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
Originally posted by gskinner at https://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 https://www.avrfreaks.net/index.p...
In future versions of AVRStudio hopefully this is fixed.
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
Just a reply to make the new post go off - the Tiny2313 was updated to include a fix for AVRStudio.
-MMC
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).
Dear Mr. Kaspar PedersenI 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
Edit: Same behaviour observed on ATMega32 (rev B), but not confirmed from Atmel on this part.
Edit: received 8/8 2005:
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.
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:
> 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
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.)
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
Device: ATMega169, 8535 + probably other devicesProblem: 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)
Here is some earlier advice I received from Atlmel:-
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.
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?).
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.
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.
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:
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.
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.
______
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.
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”.
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:
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.
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]:
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 operationWGM13..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:
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
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
----------
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.
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.
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 https://www.avrfreaks.net/index.p... for details of a case where this gave problems.
Atmel have confirmed a typo in the data Sheet regarding stack usage on the ATMega166p/324p/644p (doc8011-AVR-04/08)
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 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]
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
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: https://www.avrfreaks.net/index.p...
It is, however, implemented in the ATxmega32A4.
Device = ATxmega128A1, ATxmega32A4, probably others too.
Function = Hardware CRC
Bob Paddock in this thread https://www.avrfreaks.net/index.p... found that the CRC calculation in the XMEGA device manual is wrong and should be corrected:
[/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]
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.
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:
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: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=688049#688049
Copied here by Plons
They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/
Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips
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
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.
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.
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"
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
I have reported several errors on XMEGA datasheets and application notes to atmel:
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)
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.
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.
Several errors in XMEGA documents, shown in attached file (dac_0.pdf).
2 errors in XMEGA documents, shown in attached file (DMA_0.pdf).
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).
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).
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.
XMEGA A manual-Rev H-page 102:"XMEGA has seven different reset sources."
But XMEGA has only six different reset sources.
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.
ATmega48A: problems with ADC-mux.
See https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=794271#794271
They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/
Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips
ATMEGA 164P/324P/644p:
Errors in the Serial Port innitialisation examples:
https://www.avrfreaks.net/index.p...
Update: Reported to Atmel, They say it should be fixed in the next datasheet revision
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, r16It should be:
Code:
...
andi r16, ~(1<<WDRF)
......or similar which only clears the specified bit.
Phew... 0 << (or >>) anything is just 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.
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113437#887501
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.
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.
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:
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.
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.
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
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:
...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...
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.
avr@atmel.comHi 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
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...
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:
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
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:
The vector is normally a jump to the interrupt routine, and this jump takes three clock cycles.
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:
The vector is normally a relative jump to the interrupt routine, and this jump takes two clock cycles.
|
"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." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
The only error is the 3 instead of 2 cycles. I think their use of the word "jump" is just in the general sense meaning "some opcode that gets you from one place to another". Both JMP and RJMP achieve that. I agree that if they'd said "The vector is normally a JMP to the interrupt routine, and this jump takes three clock cycles. " then that would be wrong. (obviously the 3 cycle thing is an error though).
Device: ATtiny167
Datasheet Revision: 8265C-AVR-03/12
Feature: Dynamic Clock Switch
The code section in datasheet page 34 (non-watchdog) & page 36 (with watchdog) has a missing section of code & the CLOCK_AVAILABILITY definition.
The missing definition to be added:
#define CLOCK_AVAILABILITY 0x03
The missing section of code:
//NEW Added: Request for Clock Availability CLKSELR = ((sut << 4) & 0x30) | (clk_number & 0x0F); CLKCSR = 1 << CLKCCE; CLKCSR = CLOCK_AVAILABILITY;
Without the above section of code & definition, the CLKRDY bit in CLKCSR will NEVER be set thereby putting your code in endless loop in:
// Wait for clock validity while ((CLKCSR & (1 << CLKRDY)) == 0);
Atmel support has confirmed this error & the above missing section of code was provided by them.
My complete & tested code is below:
#define F_CPU 5000000UL #include#include #include #define CLOCK_RECOVER 0x05 #define CLOCK_ENABLE 0x02 #define CLOCK_SWITCH 0x04 #define CLOCK_DISABLE 0x01 #define WD_ARL_ENABLE 0x06 #define CLOCK_AVAILABILITY 0x03 #define WD_2048CYCLES 0x07 void ClockSwitching(unsigned char clk_number, unsigned char sut) { unsigned char previous_clk, temp; // Disable interrupts temp = SREG; asm ("cli"); // Save the current system clock source CLKCSR = 1 << CLKCCE; CLKCSR = CLOCK_RECOVER; previous_clk = CLKSELR & 0x0F; // Enable the new clock source CLKSELR = ((sut << 4 ) & 0x30) | (clk_number & 0x0F); CLKCSR = 1 << CLKCCE; CLKCSR = CLOCK_ENABLE; //NEW Added: Request for Clock Availability CLKSELR = ((sut << 4) & 0x30) | (clk_number & 0x0F); CLKCSR = 1 << CLKCCE; CLKCSR = CLOCK_AVAILABILITY; // Wait for clock validity while ((CLKCSR & (1 << CLKRDY)) == 0); // Enable the watchdog in automatic reload mode WDTCR = (1 << WDCE) | (1 << WDE); WDTCR = (1 << WDE ) | WD_2048CYCLES; CLKCSR = 1 << CLKCCE; CLKCSR = WD_ARL_ENABLE; // Switch clock source CLKCSR = 1 << CLKCCE; CLKCSR = CLOCK_SWITCH; // Wait for effective switching while (1){ CLKCSR = 1 << CLKCCE; CLKCSR = CLOCK_RECOVER; if ((CLKSELR & 0x0F) == (clk_number & 0x0F)) break; } // Shut down unneeded clock source if (previous_clk != (clk_number & 0x0F)) { CLKSELR = previous_clk; CLKCSR = 1 << CLKCCE; CLKCSR = CLOCK_DISABLE; CLKCSR = 0x80; //Errata suggestion } // Re-enable interrupts SREG = temp; } int main(void) { DDRB |= (1 << PORTB0); PORTB &= ~(1 << PORTB0); ClockSwitching(0x0D, 0x02); while(1) { PORTB ^= (1 << PORTB0); _delay_ms(100); } }
Thanks for sharing, it is now saved in my bottomless pit of AVR stuff. :-)
ATmega644(P) and ATmega1284(P):
High slewrate data on RxD0 disturbs the crystal oscillator in the AVR when it's not set to "Full swing" with the fusebits.
So either reduce the slewrate on RxD (using 10k - 100pF Low pass filter), or set the oscillator to full swing.
All credits to njepsen on the MCSelec-forum
http://www.mcselec.com/index2.ph...
I am just the messenger ;)
Nard
They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/
Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips
Atmega48A/88A/168A/328A+PA datasheet
doc: 8271G-AVR-02/2013
In section 20.7 there is a bug in the example
The assembly example is:
USART_Receive: ; Wait for data to be received in r16, UCSRnA sbrs r16, UDREn rjmp USART_Receive ; Get and return received data from buffer in r16, UDRn ret
Here the USART Data register Empty flag is checked instead of the USART Receive Complete flag.
The fun part is that the C code example below that does have the correct code:
unsigned char USART_Receive( void )
{
/* Wait for data to be received */
while ( !(UCSRnA & (1<<RXCn)) )
;
/* Get and return received data from buffer */
return UDRn;
}
AT90CAN128: aborting a pending MOb can leave CONMOB in an unexpected state
I am not sure what kind of bug this is: could be a hardware bug or could be Atmel's library at90CANlib_3_2 being buggy AND misleading.
The library's procedure to abort a MOb that was pending consists on writing 0 to the CONMOB bits. Also, the library depends on those bits being 0 to detect a MOb as being free.
Turns out that a failed MOb (e.g. because of bus errors) will retry its process, and if its CONMOB is overwritten with 0 in that situation there is a rare chance that the CONMOB will jump back to its old value. So any routine testing for CONMOB==0 will consider the MOb busy. Result: a MOb leaked and unusable until reset.
I wrote Atmel about this and their answer was that:
If you want to abort CAN communications, I would instead recommend using ABRQ in CANGCON as the means to abort. CANCDMOB is not affected by the abort, so you would still have to manage it.
... but that is not a good solution, because ABRQ aborts all MObs. I only wanted to abort one MOb.
Also they said, ...
CANCDMOB really does not indicate that a MOB is "free" in the sense that it is ready for the next transmission - other bits indicate this; the user manual is clear that CONMOB bits are not cleared once communication is performed...
Also, the manual mentions repeatedly that the CONMOB is not expected to change by itself, not even after a reset. Which makes me think that this is actually a hardware bug (no?).
Anyway, my minimal workaround is: when aborting a MOb, write 0 to CONMOB, check that the corresponding CANEN bit is 0, and rewrite the 0 to CONMOB.
Alternatively, to search for free MObs, stop checking CONMOB and switch to checking CANEN.
ATtiny13A datasheet 8126F-AVR-05/12 chapter 7.5.1.
BODCR - BOD Control Register bitnames are labeled as BODS and BODSE, while in the tn13Adef.inc are labeled as BPDS and BPDSE.
Typo in t25/45/85 datasheet, page 150, table 20-7. The rightmost column should read "Signature Byte 2" instead of 0.
The low power oscillator itself is a bug imho. I have seen it cause all manner of glitchy, impossible to debug problems, which are magically cured by going back to the full swing oscillator.
Two typing errors in ATmega64M1 datasheet (7647K–AVR–12/13 )
19.2.2 Current Source for Low Cost Traducer
An external transducer based on variable resistor can be connected to the current source. This ca be for instance:
● A thermistor, or temperature-sensitive resistor, used as a temperature sensor
● A CdS photoconductive cell, or luminosity-sensitivity resistor, used as a luminosity sensor.
Using the current source with this type of transducer eliminates the need for additional parts otherwise required in resistor
network or Wheatstone bridge.
Many AVR8 datasheets, including modern versions for e.g. Mega48 family and Mega164 family, have the "I/O pin input hysteresis vs. VCC" graph in Typical Characteristics scaled in millivolts (mV). It should be volts (V), as in e.g. Tiny1634 sheet.
ATtiny4/5/9/10 datasheet.
link: http://www.atmel.com/images/atme...
page 146, section 16.4.2
SST - Serial STore to data space using indirect addressing
This binary value is wrong....
"DS[PR] ← data 0110 0000 PR ← PR + 1 Post increment"
It should be...
"DS[PR] ← data 0110 0100 PR ← PR + 1 Post increment"
Device: MEGA644P family
Summary: Datasheet errata
Datasheet assembler examples (notably the USART) do not appear to have been updated to reflect that some registers are now outside the 'magic 32' where in and out instructions work and therefore lds and sts need to be sued, and the example code will throw errors.
Datasheet assembler examples (notably the USART) do not appear to have been updated to reflect that some registers are now outside the 'magic 32' where in and out instructions work and therefore lds and sts need to be sued, and the example code will throw errors.
Thank you.
Note that the 'magic 32' are for the single-instruction bit-manipulation and bit-testing instructions like SBI/CBI/SBIS/SBIC. Instructions like IN/OUT will work on all 64 I/O registers.
|
"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." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
stub does your datasheet contain a little note at the bottom of the examples which says:
Note: 1. See “About Code Examples” on page 8.
which in turn says
3.2 About Code Examples
This documentation contains simple code examples that briefly show how to use various parts of
the device. Be aware that not all C compiler vendors include bit definitions in the header files
and interrupt handling in C is compiler dependent. Please confirm with the C compiler documentation for more details.
The code examples assume that the part specific header file is included before compilation. For
I/O registers located in extended I/O map, "IN", "OUT", "SBIS", "SBIC", "CBI", and "SBI" instructions must be replaced with instructions that allow access to extended I/O. Typically "LDS" and
"STS" combined with "SBRS", "SBRC", "SBR", and "CBR".
Anyway assembler tragics use macros to overcome that sort comings 
AVR001: Conditional Assembly and portability macros
Device: XMEGA128A1U
Summary: Analog Comparator silicon errata
The XMEGA128A1U (and probably XMEGA64A1U) does not make AC1OUT signals available on PA6 and PB6.
Not a problem if just migrating from older XMEGA128A1 device. Could bite you if migrating from a different AU device (A4U in my case).
Workaround: AC ISR to toggle output pin if you can tolerate the latency.
Workaround: AC ISR to toggle output pin if you can tolerate the latency.
The event system can route an event sourced by AC to be sunk by a port pin.
http://www.atmel.com/products/microcontrollers/avr/avr_xmega.aspx?tab=documents
Atmel AVR XMEGA AU Manual
(file size: 7.2MB, 478 pages, revision F, updated: 04/2013)http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf
13. I/O Ports
(page 146, bottom)
13.10 Clock and Event Output
It is possible to output the peripheral clock and any of the event channels to the port pins (using EVCTRL register). This
can be used to clock, control, and synchronize external functions and hardware to internal device timing. The output port
pin is selectable. If an event occurs, it remains visible on the port pin as long as the event lasts; normally one peripheral
clock cycle.
Edit : manual
Device: ATmega328PB datasheet (complete) 40001906A, (C) 2017
Summary: PD0 incorrectly listed as RXD1 (USART1 Input Pin) on page 98 under "17.3.3. Alternate Functions of Port D". Correct assignment for PD0 is RXD0 (USART0 Input Pin) as elsewhere in datasheet (including "Table 6-1. PORT Function Multiplexing"). Also makes ATmega328PB Xplained Mini schematic more logical: unlikely to use USART0 for TXD and USART1 for RXD.
Device: ATmega328PB Xplained Mini User Guide 42469B, updated 2015-08
Summary: PD1 and PD0 ATmega328PB pins incorrectly swapped in "Table 2-10 J104 USART Header" on p.17. (ATmega328PB Xplained Mini schematic A09-2523 Rev. 4, 04.01.2017, is correct.)
The latest (0856L - Nov '16) revision of the Atmel AVR Instruction Set Manual gives the mistaken impression that an intermediary register will often be needed with the EOR instruction. In section 58.1 (p91), among the operands, the bitmask register Rr is restricted to R0 - R3. You can't use LDI to load a bitmask register with that restriction: LDI requires R16 - R31.
The problem is a typo - a missing '1': the restriction on Rr should be R0 - R31. This is hinted at by the example (in 58.2 on the same page) which uses R4 for Rr; that would be wrong if the limit of R3 were correct. More significant, the opcode shows five bits for Rr (R0 - R31) not two as it would if the limit of R3 were correct.
AVR910: In-System Programming APPLICATION NOTE
The document states that Programming Enable command ($AC 53 xx yy) gets reply ($zz AC 53 xx).
That is not correct. It does not echo AC in the second byte of the reply.
It should. It's usually the input delayed by one byte.
Note that the command in question is "Programming Enable". The echo-to-MISO likely isn't enabled until programming is enabled. That happens after the $53 is received, so echoing likely starts on the 3rd byte, echoing the second byte, $53.
Note that device datasheets are not definitive, but seem to support this interpretation:
Note that I have not confirmed on hardware what @MASIP has reported above.
|
"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." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
The latest complete datasheet (DS40001906C, dated 2018-02-22) still gives conflicting pinouts for serial ISP.
"Figure 32-6. Serial Programming and Verify, VCC = 1.8 - 5.5V" on p400 shows MOSI, MISO and SCK as PB5, PB6 and PB7 respectively. That's wrong; it appears to be copied from the datasheet for the ATmega324PB (for which those pins are correct).
For the ATmega328PB the correct pins for MOSI, MISO and SCK are PB3, PB4 and PB5 respectively. The datasheet has that correct further down the page, in "Table 32-15. Pin Mapping Serial Programming". (The schematic for the 328PB Xplained Mini board also shows the correct pins.)
Below Table 32-15 there also appears this confusing note: "The pin mapping for SPI programming is listed. Not all parts use the SPI pins dedicated for the internal SPI interface." What it means is this: The pin mapping for serial ISP is listed. There are pins dedicated for the internal SPI but not all parts use them for ISP.
I believe there an error in the ATmega48A.../328/P datasheet, dated 2018, DS40002061A.
On page 131, Section 16.9.1, the second paragraph starting "The Input Capture ..." states the need to deal with "resolution of the counter", but I think they mean "range of the counter".
Edit: Or am I missing something with respect to the term "resolution"?
"The Input Capture ..." states the need to deal with "resolution of the counter", but I think they mean "range of the counter".
This appears to be what is meant by "resolution."
See sections 15.7.1 and 15.7.2 on page 107.
--Mike
Device: ATtiny212/ATtiny412
Summary: Wrong mux table in the datasheet
Datasheet: Rev. A - 01/2017
Here is the right mux table:
Device: ATmega32U4
Summary: Errors in datasheet 7766J (04/2016), Chapter 32 "Instruction Set Summary"
I've tested the CALL and RET instructions, and their #Clocks values are wrong.
Since the Program Counter (PC) is 16 bits wide:
- the CALL instruction pushes 2 bytes on the stack,
- the CALL instruction takes only 4 cycles -- instead of 5,
- the RET instruction takes only 4 cycles -- instead of 5.
Since the wrong values might come from the copy of data corresponding to a device with a larger memory space, the values for the RCALL, ICALL, EICALL and RETI instructions should also be checked.
ATTINY1614
Datasheet says on pg337; "When the USART is set in one-wire mode, the transmitter and the receiver share the same RxD I/O pin."; (that is wrong)
One-Wire pin is the TXD pin, NOT THE RXD PIN
Microchip has confirmed that TXD is the correct pin for One-Wire. I'm in the process of trying to get Microchip to update the datasheet.
Also not specified in the datasheet for One-Wire mode...
If TX pin is set as output, ODME "Open Drain Mode Enable" does not work.
so TX port must NOT be set as output when using ODME "Open Drain Mode Enable".
This is Not specified in the datasheet.
The following statement from pg340 about one wire setup is vague.
For setting the USART in One-Wire mode, the following initialization sequence is recommended:
1) Set the TxD/RxD pin value high, and optionally set the XCK pin low.
*Needs clarification, what does "Set the TxD pin value high" mean, pullup resistors? or set as output?
*testing shows that in open drain mode, pin should NOT be set as output
2) Optionally, write the ODME bit in the USARTn.CTRLB register to '1' for Wired-AND functionality.
3) Set the TxD/RxD and optionally the XCK pin as an output.
4) Select the baud rate and frame format.
5) Select the mode of operation (enables XCK pin output in Synchronous mode).
6) Enable the transmitter or the receiver, depending on the usage
Tested and working method for 1 wire.
1) Do NOT set TxD pin as output
2) Enable Pullup Resistor on TxD pin if NOT using external pullup.
3) set bit LBME "Loop-back Mode Enable"
4) set bit ODME "Open Drain Mode Enable"
5) Use TxD pin for Transmit and Receive operations.
6) Enable the transmitter or the receiver, depending on the usage
Please also publish this in a separate Tiny1614 thread because nobody who needs it (maybe including me) will ever find it here when the time comes.
Jim
