Atmega16u2 int vector table size.

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

Hi folks,
I'm not very experienced with avrgcc, so apologies in advance if I'm just doing something dumb.

I'm trying to migrate some code from an at90usb162 to an atmega16u2.
They are 99.99% hardware compatible but I am having some minor issues. This is probably unrelated, but...

I notice that when I change the device from at90susb162 to atmega16u2 and clean/build the only change seems to be that interrupt vector table size changes from 28 entries to 37.

Don't see a larger int table in the m16u2 data sheet, so I don't know where that size increase is coming from.

This is with winavr 20100110 installed, but I also see the same thing with the AVRstudio 5 beta.

Thanks,

-carl

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

Are you sure that you haven't got it set to compile for a mgea16u4?

Regards,
Steve A.

The Board helps those that help themselves.

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

Koshchi wrote:
Are you sure that you haven't got it set to compile for a mgea16u4?

Yep, mega16u2.

When compiled for a mega16u4, the vector table extends to 0xa8 (42 vectors), which appears to be correct for that part.

-carl

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

H. Carl Ott wrote:
the only change seems to be that interrupt vector table size changes from 28 entries to 37.
The include file iom16u2.h has the wrong value in the _VECTORS_SIZE definition.
#define _VECTORS_SIZE (38 * _VECTOR_SIZE)

Unfortunately, changing 38 to 28 in this file doesn't affect the actual vector table size. The wrong value must be hard-coded somewhere in the compiler. Unless you're short on space and need the 40 bytes of Flash that are being wasted, there's no harm done.

Interestingly, the mega8U2 and mega32U2 have the same problem. Moreover, it appears that the entries in the mega8U2 vector table are 2 words unlike the other AVR devices I've seen with 8K or less of Flash which have 1 word vector tables.

edit: I intended to refer to the mega32U2 in the last paragraph rather than the mega16U2 so it was changed.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Last Edited: Thu. May 5, 2011 - 04:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dkinzer wrote:
The include file iom16u2.h has the wrong value in the _VECTORS_SIZE definition.
#define _VECTORS_SIZE (38 * _VECTOR_SIZE)

Unfortunately, changing 38 to 28 in this file doesn't affect the actual vector table size. The wrong value must be hard-coded somewhere in the compiler. Unless you're short on space and need the 40 bytes of Flash that are being wasted, there's no harm done.

This is the same conclusion that I was coming to. I was not including any io.h so assumed the table was hardcoded in the compiler itself. Parameter probably coming from an atmel .xml file at some point (just guessing).

I am surprised the problem had been there for so long and un-commented upon. Thought that in my inexperience I was just doing something wrong.

I can live with the lost bytes of flash, but it may be a bigger issue for someone more space constrained, especially on the mega8u2.

I will have to submit a bug report.

Thanks for taking the time,

-carl

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

dkinzer wrote:
The wrong value must be hard-coded somewhere in the compiler.
On further research, I believe that the over-sized vector table comes from /WinAVR_20100110/avr/lib/avr35/crtm16u2.o. If desired, one could rebuild this file with the correct _VECTORS_SIZE value.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

dkinzer wrote:
On further research, I believe that the over-sized vector table comes from /WinAVR_20100110/avr/lib/avr35/crtm16u2.o. If desired, one could rebuild this file with the correct _VECTORS_SIZE value.

Thanks for the research. I see that you got the bug submitted over at savannah.

I don't really have an environment setup to rebuild avr-libc either completely or partially. I'll just make a note of the issue and wait for a new release.

Thanks,

-carl

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

Carl,

The crtm16u2.o (and in fact ALL the crtm.o files) are all built from one single .S file:

http://svn.savannah.nongnu.org/v...

So just grab a copy of that and add gcrt1.S to your project then use -nostartfiles to over-ride the automatic inclusion of crtm16u2.o

In that file note the macro:

	.macro	vector name
	.if (. - __vectors < _VECTORS_SIZE)
	.weak	\name
	.set	\name, __bad_interrupt
	XJMP	\name
	.endif
	.endm

That basically carries on making __vectorN entries until it reaches _VECTORS_SIZE

Cliff

PS note you will have to pick up any associated support files such as macros.inc too.

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

Cliff,
Thanks for that info and insight on the inner workings of winavr.

I added gcrt1.S to my project (and macros.inc & sectionname.h)

Edited iom16u2.h to have the correct table size
#define _VECTORS_SIZE (29 * _VECTOR_SIZE)

And all seems to be compiling as expected.
Hardly any hoop jumping at all. :)

Thanks again,

-carl