| Author |
Message |
|
|
 Posted: Jun 08, 2012 - 08:25 PM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
Firstly please don't ask why I am doing this exercise on this chip as it is perfectly able to connect via USB. It is the only mega I have around at the moment and so I am using it.
While trying to adapt the STK500v2 compatible bootloader to use on the ATmega32U4 I came across this code. I understand what the code does, one macro uses LPM the other uses ELPM but it gives an error for this chip. According to the datasheet the ELPM instruction is available.
Code:
#if (defined(RAMPZ)
data = pgm_read_word_far(address);
#else
data = pgm_read_word_near(address);
#endif
Code:
Error: illegal opcode elpm for mcu atmega32u4
Both the AS6 Toolchain and WinAVR give the same error.
Is this an error in the compiler or the data sheet?
Also, what are the specific differences between the two instructions?
EDIT: Moderator I couldn't, at first, decide whether this belonged in the AVR forum or the GCC forum. Please move it to the GCC forum as it clearly looks like it should be there.
EDIT2: Maybe EDIT above is wrong. You decide. |
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
Last edited by larryvc on Jun 09, 2012 - 01:08 AM; edited 3 times in total
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 10:39 PM |
|
Joined: Sep 12, 2009
Posts: 2398
Location: Sacramento, CA
|
|
| The difference is between chips that can access all bytes in program memory using 16 bits of address ( <=64k flash), and those that require 24 bits. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 11:35 PM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
So the ATmega32U4 datasheet, still Preliminary, revision F, updated: 11/2010, must be incorrect as this chip has 32K flash. I had already circumvented the problem, before posting, by changing the #if preprocessor directive to:
Code:
#if (defined(RAMPZ) && !defined(__AVR_ATmega32U4__))
|
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
|
| |
|
|
|
|
|
|
Posted: Jun 09, 2012 - 12:24 AM |
|
Joined: Jun 22, 2004
Posts: 3849
Location: South West Utah, USA
|
|
The RAMPZ register only exists to support 8 bit AVRs with more than 64k bytes FLASH that need more than 16 bits of FLASH byte address (like an ATmega128 chip). Since FLASH is addressed as 16 bit words by the program counter (up to 128k bytes which is 64k words of FLASH), RAMPZ is only needed to address more than 64k bytes (32k words) of FLASH that exceed 16 bits of Z register pair address (like ELPM in a 128k byte FLASH AVR). Yet the ATmega32U4 data sheet Register Summary claims RAMPZ exists with defined bits RAMPZ0 and RAMPZ1. If RAMPZ is defined for this chip, it is an error. However, since this data sheet shows it exists, it probably is defined when it should not be defined.
The EIND register only exists to support 8 bit AVRs with more than 128k bytes FLASH that need more than 16 bits of address for the program counter (like the 17 bit program counter ATmega2560 AVR). Yet the ATmega32U4 data sheet Instruction Set Summary claims your chip has EIJMP and EICALL instructions. Another obvious error.
ATMEL is famous for copying mass information from other data sheets when creating a new data sheet. Then ATMEL does not do a good job of cleaning up all the wrong information that got copied. If this bad information makes it into the master chip XML description file, then these errors get replicated in lots of other places. This would explain why your AVR with only 32k bytes of FLASH would have RAMPZ defined. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 09, 2012 - 01:04 AM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
Thanks for the replies guys.
I did some more digging and found that the iom16u4.h and iom32u4.h files in both WinAVR and AS6 have RAMPZ, RAMPZ0, EIND, and EIND0 defined.
In the AS6 ATmega16U4.xml and ATmega32U4.xml files EIND is defined but RAMPZ is not. |
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
|
| |
|
|
|
|
|
|
Posted: Jun 09, 2012 - 12:24 PM |
|
Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| This would therefore appear to be a bug in the AS6 toolchain - please make sure it gets into the Atmel bug-tracker or it'll never be fixed. Should I move this to AS6 forum so the gnomes of the North get to see it? |
_________________
|
| |
|
|
|
|
|
|
Posted: Jun 09, 2012 - 01:37 PM |
|
Joined: Sep 04, 2002
Posts: 21248
Location: Orlando Florida
|
|
| I assume that pointing out the bug here is sufficient. They claim they read the forum. |
_________________
Imagecraft compiler user
|
| |
|
|
|
|
|
|
Posted: Jun 09, 2012 - 05:15 PM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
|
clawson wrote:
This would therefore appear to be a bug in the AS6 toolchain - please make sure it gets into the Atmel bug-tracker or it'll never be fixed. Should I move this to AS6 forum so the gnomes of the North get to see it?
I will post a bug report now.
Yes, move it please.
Perhaps with this:
Atmel Gnomes Look here!!!  |
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
|
| |
|
|
|
|
|
|
Posted: Jun 09, 2012 - 07:59 PM |
|
Joined: Jan 23, 2004
Posts: 9817
Location: Trondheim, Norway
|
|
Gnomes are on holidays, so all you'll get is the trained monkeys. Put it in the tracker (http://asf.atmel.com/bugzilla/) and I'll make sure it's transferred to the internal system.
FYI, in my own projects I use this check:
Code:
#if (FLASHEND > 0xFFFF)
Rather than a check for the existence of RAMPZ.
- Dean  |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
