ATmega32U4 ELPM instruction unsupported?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

	#if (defined(RAMPZ)
								data	=	pgm_read_word_far(address);
	#else
								data	=	pgm_read_word_near(address);
	#endif
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.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Jun 9, 2012 - 12:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

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

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:

#if (defined(RAMPZ) && !defined(__AVR_ATmega32U4__))

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

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.

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

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.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

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?

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

I assume that pointing out the bug here is sufficient. They claim they read the forum.

Imagecraft compiler user

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

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!!! :shock: :shock: :shock:

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

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:

#if (FLASHEND > 0xFFFF)

Rather than a check for the existence of RAMPZ.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!