AVRLIB on avr-gcc

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

Hi all,
I have used AVRLIB with avr-gcc previously,I have recently installed TinyOS (An Event based Operating System) on my Ubuntu 10.10 after which I am unable to use AVRLIB. I get the following error when I go to "avrlib/examples/"
and type make all

Quote:
make -C a2d all
make[1]: Entering directory `/home/sai/Documents/My_Work/AVRLIB/avrlib/avrlib/examples/a2d'
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex a2dtest.elf a2dtest.eep
avr-objcopy: there are no sections to be copied!
avr-objcopy: --change-section-lma .eeprom=0x00000000 never used
make[1]: *** [a2dtest.eep] Error 1
make[1]: Leaving directory `/home/sai/Documents/My_Work/AVRLIB/avrlib/avrlib/examples/a2d'
make: *** [a2d] Error 2

I have added AVRLIB in my environmental variables list. I also searched the forum and got a relative post regarding this and I have done that also. This is the link.

http://www.avrfreaks.net/index.p...

The tools I am using are

Quote:

GNU objcopy 2.17 + coff-avr-patch (20050630)
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.

Using built-in specs.
Target: avr
Configured with: ./configure --prefix=/usr --disable-libssp --disable-nls --enable-languages=c,c++ --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --target=avr --with-ld=/usr/bin/avr-ld --with-as=/usr/bin/avr-as
Thread model: single
gcc version 4.1.2

Any other suggestions?

Thank you

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

AVR Studio gets round this with:

%.eep: $(TARGET)
	-avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@ || exit 0

That "|| exit 0" dumps the error condition.

Or one simple solution is simply to add:

#include 
char unused EEMEM;

to one of the source files. That creates an entry in the .eeprom section to give it something to chew on.

As this is specific to GCC I'll move the thread.

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

clawson wrote:
That "|| exit 0" dumps the error condition.
But that does not omit an error message. So if an empty eeprom section would be the cause, you would see the same error message with that command line.

Quote:
avr-objcopy: there are no sections to be copied!
IMO the problem is that objcopy doesn't see any sections at all.

Quote:
GNU objcopy 2.17 + coff-avr-patch (20050630)
Perhaps a combination of a compiler generating elf output and an objcopy expecting coff by default?

Stefan Ernst

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

Thank you very much for the valuable information Clawson.
I have added as you said

Quote:
#include
char unused EEMEM;

in my source , I was able to get over it and program got compiled.
Can you tell me what was the error about and how did I sorry rather you solve it.Also please tell any relevant documents that could solve all my ambiguity of all the compiler options and makefile's.
Thanks again

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

Quote:

Can you tell me what was the error about and how did I sorry rather you solve it

The line in the Makefile is the one that creates a .eep file to hold the initial value of any EEPROM variables which will be in the .eeprom section in the .elf file. If however you don't actually have ANY such variables the .elf file simply doesn't have a .eeprom section so avr-objcopy returns an ERRORLEVEL to say "I couldn't do what you asked" and make takes this as a fatal error and stops the build process.

I have to admit that I cheated a bit. I didn't just think this up but about 3-4 years ago Atmel made an issue of AVR Studio with the avr-gcc plugin that would not work for this very reason. Clearly while Atmel had been testing it internally all their test programs must have had at least one EEMEM variable so they never noticed. It only took about 3 nanoseconds after they released the code for the world and his wife (who weren't using EEMEM variables) to wake up and knock down Atmel's front door in the rush to get the issue resolved - htey fixed it pretty quickly and the fix was (I thought!) the change I mentioned above using "|| exit 0". But maybe I didn't remember the details quite straight - it was a few years ago and alcohol is slowly eroding every last brain cell I own.

Cliff

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

I think "In between you have lots of grey celss left"
Also can you just guide me to some documents to get me overcome this kind of errors. I just wanna know all that was written in the makefile so that i can do the same development in Ubuntu.
Thanks again

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

Well the best way to understand Makefiles is actually the GNU "make" manual:

http://www.gnu.org/software/make...

(it's surprisingly good and easy to read compared to a lot of GNU manuals). But that only tells you how the make rules are constructed. The use of tools such as objcopy, objdump, nm, ar and other such tools is given in the "binutils" manual:

http://sourceware.org/binutils/d...

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

Thank you . Will go through them.

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

hai ,
The problem was rectified and I compiled the code of one of the examples.But when I put that code into AVR. The code seems be repeating by itself in a recursive way. I burnt the same code from another system in which there was no compilation error.The code did its usual job. Any suggestions?

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

No suggestions yet. Is this the weekend effect

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

Quote:

No suggestions yet.

Probably because your previous post made no sense - you probably know what you are talking about - I doubt anyone here can guess. You say
Quote:

The code seems be repeating by itself in a recursive way

What does that mean and how are you observing this? Do you mean the AVR keeps restarting - when using GCC that's a classic sign of an interrupt that's been enabled for which no ISR() handler has been provided (because the default one does a JMP 0).

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

Ok. I will put my question this way. I compiled the code on my system with latest avr-gcc and the code got into some recursive mode i.e my code gets executed again and again.
I found this because I did the same execution on other computer with Fedora 9 with an earlier avr-gcc version and it got compiled and executed perfectly.
I put that question because I thought as AVRLIB has not been updated since long, there might be some unknown bug in its make process. Sorry I would look again and get back to you on that.

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

Quote:

I compiled the code on my system with latest avr-gcc and the code got into some recursive mode i.e my code gets executed again and again.

Are you talking about the compiler having some "looping" fault when it tries to compile the code or are you talking about repeated restarts once the code is built and running on the AVR? If the latter it's almost certainly what I suggested above.

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

Ok, so how can I get rid of this because that has got to be something wrong with the compilation process because the same code gives output if compiled with earlier versions. How to correct the looping fault of the compiler.

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

Well personally I still don't know whether you are talking about a compilation problem or a runtime problem so I guess I'm out as I can't help if I don't understand the problem or what you are asking. Hopefully someone else can decipher what you are talking about?