ATmega2560 project working with 4.1.1 but not 4.3.0

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

Hi

Compiling for the 2560 I get a working image if I use avr-gcc 4.1.1 as shipped with WinAVR_2007012, but if I try and use avr-gcc version 4.3.0. (from WinAVR-20080610) the resulting images do not work - it is almost as if there is something corrupting the stack pointer; if I try and step through the code using the USB JtagMkII in AVR Studio I get weird behaviour where the code returns from function calls to unexpected places.

We are optimising for size. The command line options used are:
avr-gcc -Os -Wundef -Wall -gstabs -mcall-prologues -fno-strict-aliasing -frename-registers -DCOMPILER_GCC -mmcu=atmega2560

At the minute I can build with the older version but I would rather not be left behind as the toolchain matures.

Does anyone know what could be causing the problem? or how I might go about fixing it?

Thanks for any help you can provide.
Best regards,
sd

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

Do you have code over the 128 KByte Flash boundary? If so, you may be running afoul of gcc's use of 16-bit function pointers.

Gcc 4.3.0 is far more aggressive about inlining functions than the earlier versions. It's a trade-off between fast and small that the larger processors (ARM, x86, etc) made that is making the AVR life miserable. In your (our) case, this means that functions that used to be under the 128 KByte boundary are now over it. Pointers to those functions can go awry.

See my tutorial [TUT][SOFT]

FreeRTOS for ATmega2560/1<br />
for more information and ways to help the problem.</p>
<p>
servodude wrote:
We are optimising for size. The command line options used are:[code]avr-gcc -Os -Wundef -Wall -gstabs -mcall-prologues -fno-strict-aliasing -frename-registers -DCOMPILER_GCC -mmcu=atmega2560
Umm, the -Os option isn't really an "optimize for size". Go read the GCC manual. On the other hand, there isn't really an "optimize for size" option. Finally, I always use -Os, so you're at least in good company! :wink:

I am running an ATMega2560 with code compiled on the latest GCC (well, the latest released WinAVR). Trust me, it can be done.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Thanks for that Stu,

it has given us something to investigate. Thanks also for the link to the tutorial; I'll have a read at that and see what i can learn.

Good to know it can be done.

Thanks again,

sd

stu_san wrote:
Do you have code over the 128 KByte Flash boundary? If so, you may be running afoul of gcc's use of 16-bit function pointers.

Gcc 4.3.0 is far more aggressive about inlining functions than the earlier versions. It's a trade-off between fast and small that the larger processors (ARM, x86, etc) made that is making the AVR life miserable. In your (our) case, this means that functions that used to be under the 128 KByte boundary are now over it. Pointers to those functions can go awry.

See my tutorial [TUT][SOFT]

FreeRTOS for ATmega2560/1<br />
for more information and ways to help the problem.</p>
<p>
servodude wrote:
We are optimising for size. The command line options used are:[code]avr-gcc -Os -Wundef -Wall -gstabs -mcall-prologues -fno-strict-aliasing -frename-registers -DCOMPILER_GCC -mmcu=atmega2560
Umm, the -Os option isn't really an "optimize for size". Go read the GCC manual. On the other hand, there isn't really an "optimize for size" option. Finally, I always use -Os, so you're at least in good company! :wink:

I am running an ATMega2560 with code compiled on the latest GCC (well, the latest released WinAVR). Trust me, it can be done.

Stu