no way to compile code for atxmega256a3bu w/ avr-libc

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

Hi!

I bought atxmega xplained a3bu - with atxmega256a3bu mcu. I'm trying to compile "hello world" program for it, but without any success.

The code is simple:

#include 
#include 

int main(void) {
  PORTR.DIRSET=3;
  for(;;) {
    _delay_ms(1000);
    PORTR.OUTTGL=3;
  }
  return 0;
}

This board has two leds connected to portr pin 0 and pin 1. This should just make the leds blink.

I'm working on Linux, I have avr-gcc 4.7.0 and avr-libc 1.8.0 (only minor change compared to 1.7.1)
These are latest versions available.

EDIT: This is my firt atxmega. For atmega my standard toolchain works without any problem for a long time.

When I try to compile it, I get following error:

$ avr-gcc -mmcu=atxmega256a3bu -Os -Wall -I./ -I. main.cpp -o main.elf
In file included from main.cpp:2:0:
/usr/lib/gcc/avr/4.7.0/../../../../avr/include/avr/io.h:428:6: warning: #warning "device type not defined" [-Wcpp]
main.cpp: In function 'int main()':
main.cpp:8:3: error: 'PORTR' was not declared in this scope

And that's right, there is no include file for atxmega256a3bu (iox256a3bu.h) in avr-libc. I found that atmel has extra patches at http://distribute.atmel.no/tools... so I've added them to avr-libc and tried to rebuild it.

It failed with

configure.ac:1311: required file `avr/lib/avrxmega6/atxmega256a3bu/Makefile.in' not found

OK, another obstacle, but they do not contain anything special, so I've copied there the one from atxmega256a3b and just made necessary change in that file. Original patch adding support does not contain this part.

with avr-libc+patch, I got that error again. PORTR not defined, but "device type not defined" warning is gone. There is iox256a3bu.h now, but there are only two lines (the same two lines that adds the patch from atmel) and that's obviously not sufficient. For other atxmega... those files (iox???.h) contains all definition and has much much more than 2 lines (iox192a3.h has 6917 lines).

Desperate, I tried atmel's toolchain from:
http://www.atmel.com/tools/ATMEL...
and uninstalled original avr-gcc and avr-libc to be sure, only the new one is used.

I got following error:

In file included from main.cpp:3:0:
/home/mihl/myroot/programovani/avr/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h: In function 'void _delay_ms(double)':
/home/mihl/myroot/programovani/avr/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:149:42: error: 'fabs' was not declared in this scope
/home/mihl/myroot/programovani/avr/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:149:43: error: 'ceil' was not declared in this scope
/home/mihl/myroot/programovani/avr/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h: In function 'void _delay_us(double)':
/home/mihl/myroot/programovani/avr/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:226:42: error: 'fabs' was not declared in this scope
/home/mihl/myroot/programovani/avr/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:226:43: error: 'ceil' was not declared in this scope
make: *** [main.o] Error 1

wondering if it's the only problem, I've removed delay usage from the code. Now I get:

/home/mihl/myroot/programovani/avr/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.5.1/../../../../avr/lib/avrxmega6/crtx256a3bu.o: In function `__bad_interrupt':
/home/tools/hudson/workspace/avr8-gnu-toolchain/src/avr-libc/crt1/gcrt1.S:195: undefined reference to `RAMEND'
/home/tools/hudson/workspace/avr8-gnu-toolchain/src/avr-libc/crt1/gcrt1.S:195: undefined reference to `RAMEND'
collect2: ld returned 1 exit status

Is there any way how to compile code for xmega-a3bu xplained or just atxmega256a3bu? Or atmel sells chips we can't compile code for?

Thanks for any help

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

At present only Atmel have added support for that device to their own Toolchain that they only build a Windows based distribution for (bundled as part of AS5 and 6)

If you get their set of patches in theory you could build a 4.5.3 like their's on Linux.

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

If your toolchain's got support for the non-U variant, and you can live without the 'U' features, then you can just compile for the xmega256a3b.

The XMega256A3B and XMega256A3BU have the same signature.

Nigel Batten
www.batsocks.co.uk

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

I am not sure about such changes in the structure of avr-libc; may be you have to run the bootstrap script after such changes and before configure.

You can install several, independent gcc toolchains, even without admin rights and in your home drive if you like.

Just choose the same --prefix while building the tools and run the generated compiler by it's absolute path name or by setting PATH appropriately.

4.7.0 is discouraged for that device. If you run linux, just use HEAD 4.7-branch to build instead of from 4.7.0-release tag.

See Bugs already fixed in 4.7.1 branch compared to 4.7.0 release.

Time was too short to complete XMEGA support for the 4.7.0 release. GCC release management won't wait for AVR changes, no matter how important.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
I am bot sue about avr-libc; may be you have to run the bootstrap script after changes and before configure.
I did that.
Quote:
You can install several, independent toolchains toolchains, even without admin rights and in your home drive if you like.
I have admin rights. I'm also package maintainer (not of avr tools) in Fedora Linux, so it's no problem for me to add patches to avr tools packages.
Quote:
4.7.0 is discouraged for that device. If you run linux, just use HEAD 4.7-branch to build instead of from 4.7.0-release tag.
Well, I won't use 4.7.0 for atmega neither, because of this bug http://gcc.gnu.org/bugzilla/show... . I was just using it for testing support of those MCUs

Anyway, my issue is not with avr-gcc, but with avr-libc.

I need usb peripheral from a3bu, so I'll try to compose atxmega256a3bu support from atxmega256a3b and atxmega128a1u (and verify addresses with datasheet).

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

Quote:

Anyway, my issue is not with avr-gcc, but with avr-libc.

As I said above (it was me, really) under GPL Atmel really should be publishing patches for the AVR-LibC they chose to accompany 4.5.3 in Toolchain (also AS5/6) so you should be able to use those to make a local AVR-LibC with U support.

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

WrightFlyer wrote:
Quote:

Anyway, my issue is not with avr-gcc, but with avr-libc.

As I said above (it was me, really) under GPL Atmel really should be publishing patches for the AVR-LibC they chose to accompany 4.5.3 in Toolchain (also AS5/6) so you should be able to use those to make a local AVR-LibC with U support.

Well, to be pedantic, avr-libc's license is the 3-clause BSD license, not GPL. This means that, technically, the patches don't have to be published. HOWEVER! I honestly think that the fact that they are not published is an oversight, than anything on purpose.

In AS6 the patches can be found in this directory:
C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.3.2.31\AVRToolchain\source

Then there are subdirectories underneath that for the avr and avr32 (i.e. UC3 product line) targets. In the avr32 directory, patches are published for newlib, the Standard C library that is used for that target. Newlib has very similar licensing (I say similar, because it has a boatload of different licenses, all very similar to each other and many of them BSD licenses). If we're publishing patches to newlib, then we should be publishing patches to avr-libc.

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

They should simply be pragmatic and business oriented.

Their 'job' is to sell hardware: chips. The easier it is to write code for them, the more they will sell.

At least on the software side of things they should be as open as possible, especially as the backbone of their IDE is based on open source tools. IMHO even having to register to download the toolchain sucks. And having several hundreds of people reporting and possibly even fixing bugs for free is not to be frowned upon.

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

Eric,

I was not having a go about GPL infringement (and I forgot about LibC being BSD) but simply saying that a source of patches would be that toolchain for the OP trying to build on Linux. That in itself raises another question. After downloading 700MB of AS6 setup.exe file how does a Linux user only interested in the patches extract them? It may be easier if the patches themselves were simply put online somewhere ;-)

Cliff

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

Your sample code from there looks reasonable now. It was a typo in the avr backend (PR53033) as you already know. It is fixed now.

avrfreaks does not support Opera. Profile inactive.

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

EW wrote:
Well, to be pedantic, avr-libc's license is the 3-clause BSD license, not GPL. This means that, technically, the patches don't have to be published. HOWEVER! I honestly think that the fact that they are not published is an oversight, than anything on purpose.

I sent my questions to atmel support. Waiting for answer

SprinterSB wrote:
mihlit:
http://gcc.gnu.org/PR52415
Your sample code from there looks reasonable now. It was a typo in the avr backend (PR53033) as you already know. It is fixed now.

Thanks for looking at it. I'll try it once there is new gcc snapshot (which should happen on sunday - afaik).

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

clawson wrote:
Eric,

I was not having a go about GPL infringement (and I forgot about LibC being BSD) but simply saying that a source of patches would be that toolchain for the OP trying to build on Linux. That in itself raises another question. After downloading 700MB of AS6 setup.exe file how does a Linux user only interested in the patches extract them? It may be easier if the patches themselves were simply put online somewhere ;-)

Cliff

Are these patch repositories up to date?
http://distribute.atmel.no/tools...

http://distribute.atmel.no/tools...

http://distribute.atmel.no/tools...

[edit]
I note that Atmel has finally updated the standalone toolchain download web pages. Now you can access a direct download for toolchain 3.3.2 (the version apparently bundled with Atmel Studio 6).

- for Windows
http://www.atmel.com/tools/ATMEL...

- and for Linux
http://www.atmel.com/tools/ATMEL...

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

Quote:

Are these patch repositories up to date?

How can one tell? There have been several issues of avr-gcc 4.5.1 in "Toolchain". The one I have on my PC now comes from AS5.1 and is:

avr-gcc (AVR_8_bit_GNU_Toolchain_3.3.1_445) 4.5.1

So I have the 4.5.1 from Toolchain build 445. Now how one can tell whether the patches above are the ones applying to build 445 in particular is anyone's guess.

I don't know (as I'm holding out for the release version of 6.0 so I only have to make the 700MB download once) whether 6.0 has a different build of toolchain and could it have a different 4.5.1 (and 1.7.1 and so on) patch set or not.

Maybe the URL to those patches could include the toolchain version/build number or perhaps the pages themselves could identify it.

Assuming 5.0Beta also had a 4.5.1 (did it?) I sure as heck would not want to build using its patch set!

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

Interesting, Cliff... My version of AVR Studio 5.1 claims to be

avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.3.1_466) 4.5.1

So clearly you've got a different build of toolchain than me, and both of them used 4.5.1 as a starting point.

Anyway, it clearly would have been more useful if the patch repository was released as an web-browseable SVN (or equivalent) repository, so we can go back in time to see tagged snapshots of different patch sets corresponding to historical toolchain releases. One can dream...

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

Maybe there is a source directory within the distribution, just like as with good old WinAVR that shipped it's patches against the FSF releases?

avrfreaks does not support Opera. Profile inactive.

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

Luke,

Now I'm really confused. I *thought* there'd only been one issue of 5.1 and I was pretty sure that's where my toolchain was from. In Help-About what do you see? Mine says 5.1.148

Cliff

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

SprinterSB wrote:
Maybe there is a source directory within the distribution, just like as with good old WinAVR that shipped it's patches against the FSF releases?

That's an affirmative for a source directory in AVR Studio 5.1.

Path:
PROGRAMFILES\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1.27\AVRRoolchain\source\avr\

It includes sets of patches for GCC 4.5.1, and for bintuils 2.20.1. Both of them appear to contain many more patches than were listed on the website I linked to above.

It does not appear to include any patches for avr-libc. Either they are keeping those patches secret (fully within their rights as a BSD-licensed library), or else they really aren't using any patches against their selected version of avr-libc.

Last Edited: Mon. Apr 23, 2012 - 04:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Luke,

Now I'm really confused. I *thought* there'd only been one issue of 5.1 and I was pretty sure that's where my toolchain was from. In Help-About what do you see? Mine says 5.1.148

Cliff

Atmel AVR Studio 5 (Version: 5.1.208)

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

Rats! I missed an issue of 5.1 :-(

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

clawson wrote:
Rats! I missed an issue of 5.1 :-(
Maybe you'd notice it, if Atmel's script kid^H^H^H^H^H^H^H^H^H^Hhigh esteemed web developers would fix the What's Changed feature.
lfmorrison wrote:
I note that Atmel has finally updated the standalone toolchain download web pages. Now you can access a direct download for toolchain 3.3.2 (the version apparently bundled with Atmel Studio 6).
Thanks; I wouldn't notice either.

Why am I not surprised seeing the confusing version numbers? :-?

JW

Attachment(s): 

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

Oh, no joy, although at the beginning I was enthusiastic - THE ANNOYING FORM CAME UP PRE-FILLED!

But it then gave me this link, which downloaded a zipfile too small to be true. Indeed, it contains a single textfile, dummy-file.txt, with the following text:

Quote:
Who are you calling "dummy"?

Okay guys, this is very funny...

JW

PS. The file name contains "3.3.1", why am I not surprised at all?

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

Quote:

Okay guys, this is very funny...

This is the second time someone's posted on Freaks about this. Atmel can you acknowledge that someone from your company is listening and that you have matters in hand to fix what's obviously a hack of your website?

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

Hi Cliff,

Sorry, but I'm on day 8 of having the flu (and still feel pretty terrible), and so have not been as diligent about checking the forums. This is the first that I've heard of the site being hacked.

Can you send me the details via email?

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

You have mail.

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

Something have changed, as the link is not a zip anymore (with the bogus file), but an exe.

The 3.3.1/3.3.2 discrepancy remained, though. The download's name contains "3.3.1.1020".

JW

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

For those who want to build their own packages, I've extracted avrlibc patch from atmel's avr toolchain 3.3.2

http://mihlit.cz/smetiste/avrlibc.patch.bz2

Together with avr-gcc 4.7.x snapshot, I can compile atxmega256a3bu code with my own toolchain again.