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).
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.
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:
Quote:
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, ...
Quote:
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...
Which is true according to the documentation, which mentions that CANEN is the register to check for availability of MObs. But that means that the library is pretty b0rked, since it never even refers to the CANEN registers.
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.
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.
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
Posted by Stub_Mandrel: Sun. Mar 27, 2016 - 10:55 AM
1
2
3
4
5
Total votes: 0
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
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.
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.
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.
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"?
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.
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).
- Log in or register to post comments
TopDevice: 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:
The missing section of code:
Without the above section of code & definition, the CLKRDY bit in CLKCSR will NEVER be set thereby putting your code in endless loop in:
Atmel support has confirmed this error & the above missing section of code was provided by them.
My complete & tested code is below:
Once an engineer, forever an engineer
- Log in or register to post comments
TopThanks for sharing, it is now saved in my bottomless pit of AVR stuff. :-)
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopATmega644(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
Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips
- Log in or register to post comments
TopAtmega48A/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:
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:
- Log in or register to post comments
TopAT90CAN128: 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:
... but that is not a good solution, because ABRQ aborts all MObs. I only wanted to abort one MOb.
Also they said, ...
Which is true according to the documentation, which mentions that CANEN is the register to check for availability of MObs. But that means that the library is pretty b0rked, since it never even refers to the CANEN registers.
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.
- Log in or register to post comments
TopATtiny13A 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.
RES
- Log in or register to post comments
TopTypo in t25/45/85 datasheet, page 150, table 20-7. The rightmost column should read "Signature Byte 2" instead of 0.
I have no special talents. I am only passionately curious. - Albert Einstein
- Log in or register to post comments
TopThe 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.
- Log in or register to post comments
TopTwo 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.
RES
- Log in or register to post comments
TopMany 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.
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
- Log in or register to post comments
TopATtiny4/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"
- Log in or register to post comments
TopDevice: 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.
It's me again...
- Log in or register to post comments
TopThank 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]
- Log in or register to post comments
Topstub does your datasheet contain a little note at the bottom of the examples which says:
which in turn says
Anyway assembler tragics use macros to overcome that sort comings
AVR001: Conditional Assembly and portability macros
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopDevice: 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.
- Log in or register to post comments
TopThe event system can route an event sourced by AC to be sunk by a port pin.
Edit : manual
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopDevice: 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.
- Log in or register to post comments
TopDevice: 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.)
- Log in or register to post comments
TopThe 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.
- Log in or register to post comments
TopAVR910: 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.
- Log in or register to post comments
TopIt should. It's usually the input delayed by one byte.
- Log in or register to post comments
TopNote 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]
- Log in or register to post comments
TopThe 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.
- Log in or register to post comments
TopI 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"?
- Log in or register to post comments
TopThis appears to be what is meant by "resolution."
See sections 15.7.1 and 15.7.2 on page 107.
--Mike
- Log in or register to post comments
TopDevice: ATtiny212/ATtiny412
Summary: Wrong mux table in the datasheet
Datasheet: Rev. A - 01/2017
Here is the right mux table:
- Log in or register to post comments
TopDevice: 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.
- Log in or register to post comments
TopPages