More Bootloader Problems

This is a similar issue with the other bootloader questions. I copy / pasted the bootloader files from Berlios, similar to CompulsiveCoder. So maybe a character conversion is the issue. I'll watch that thread.

I'm trying to compile the bootloader with the accompanying Makefile

And I get this in my terminal window

Paul-Badgers-Computer:/Applications/DevelopmentApps/arduino-0008/Boot168 paul$ make make: ** No targets. Stop.

I take this to be some kind of path problem. The bootloader code and makefile are in a folder, in the arduino folder.

I have cd'ed to that directory. I attempted to included the path of avr-gcc by editing ~/.profile

Is there a way to know what the "target" is that make is not finding?

Terminal yields this

Paul-Badgers-Computer:/opt/local/bin paul$ echo $PATH /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/Developer/Tools:/Applications/DevelopmentApps/arduino-0008/tools/avr/bin

I'm on a Mac using 10.3.9

Thanks in advance for anybody that can shed some light on this.

paul badger

The gcc command successfully generates a .o file - is this the hex file I need for the chip or does it require further processing?

Paul-Badgers-Computer:/Applications/DevelopmentApps/arduino-0008/Boot168 paul$ avr-gcc -mmcu=atmega168 -c ATmegaBOOT_168.c Paul-Badgers-Computer:/Applications/DevelopmentApps/arduino-0008/Boot168 paul$ ls ATmegaBOOT_168.c ATmegaBOOT_168.o Makefile

paul

The hex depends on the elf.

%.hex: %.elf
$(OBJCOPY) -j .text -j .data -O ihex $< $@

The elf depends on the object(s) but also links in the libraries.

$(PROGRAM).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)

The object depends on the source C file(s) called PROGRAM in this makefile.

OBJ = $(PROGRAM).o

Program is defined as

PROGRAM = ATmegaBOOT

I guess it appends the “.c” in a built-in rule.

Any way, I have modified the makefile and the C file to the point where it will also produce an object (.o), but it doesn’t link to form the elf.

$ make
/WinAVR/bin/avr-gcc -g -Wall -Os -mmcu=atmega8 -Datmega8 -DF_CPU=16000000 -DBAUD
_RATE=19200 -I/WinAVR/include -c -o ATmegaBOOT.o ATmegaBOOT.c
/WinAVR/bin/avr-gcc -g -Wall -Os -mmcu=atmega8 -Datmega8 -DF_CPU=16000000 -DBAUD
_RATE=19200 -I/WinAVR/include -Wl,-Map,ATmegaBOOT.map,–section-start=.text=0x1c
00 -o ATmegaBOOT.elf ATmegaBOOT.o
\WinAVR\bin…\lib\gcc\avr\3.4.6…\avr\bin\ld.exe: address 0x21ac of A
TmegaBOOT.elf section .text is not within region text
make: *** [ATmegaBOOT.elf] Error 1

$

David,

Thanks for making a new Makefile for the NG

Any clue as to which rule is missing?

Paul-Badgers-Computer:/Applications/DevelopmentApps/arduino-0008/Boot168 paul$ make ng
make: *** No rule to make target `ng’. Stop.

Paul

You might have carriage returns in the file that are confusing make. Alternatively, you might not have any and need them. Or you might not have tabs before the commands (in the rules).

I get this same error or a very similar error, even when I try to compile the bootloader c and makefile that came with the Arduino. I saw on some avr forums that this might be a problem with gcc making the code too large and you can add in some commands that reduce the size. I am using windows XP, does anyone have any suggestions?

Which bootloader? What error do you get?

It's the Arduino bootloader, that comes with Arduino it's in hardware/bootloaders/atmega8. I have an Atmega 8 evaluation board with an 8MHz crystal, so I want to tweak the bootloader to run with the 8MHz clock. Before I go messing with the system frequency I tried to compile the provided code to make sure I had everything set up. It compiles fine, but the linker has some problems generating a HEX file. I get the error: address 0x203e of ATmegaBOOT.elf section .text is not within region text. make: *** [ATmegaBOOT.elf] Error 1

From the .map file, I see that the text size is 0x2000 so it looks like the compiled code is 0x3e over the max size of the bootloader. Is this true? How can I reduce the size? What did the people publishing the Arduino software do to get a HEX file.

What version of avr-gcc are you using? I think we compiled it with 3.4 something; version 4 seems to generate a bigger hex file.

I was using avr-gcc-4.1.2, thanks for getting back to me. Using the older version should do the trick.

Hi

How can I install a particular version (3.4) of agv-gcc? I normally use Synaptic on Ubuntu (Intrepid), but there doesn’t seem to be a way to do it in there. Is there a BASH way to force a particular version?

My default version is 4.3.0 and I need to reduce the power up timeout of an ATMega8 bootloader from 6 seconds to <1 second.

Thanks

I know this is an ancient thread, but I ran into this same issue compiling a tweaked Sanguino bootloader. Out of the box, recent avr-gcc versions (arduino-0018 uses 4.3.2) generate much larger code files. I don't know if they changed the default optimizations, the libraries grew or what, but this helped for me:

In the Makefile, change the OPTIMIZE line from

OPTIMIZE = -O2

to

OPTIMIZE = -Os -funsigned-char -funsigned-bitfields -fno-inline-small-functions

I didn't spend the time trying to get the actual (burnable) executable size, but with these optimizations the resulting .hex file shrank from 6.5k to 5.4k, and fit within the boot block again.

From the Arduino environment:

The Arduino command line, indeed, uses -Os

It also uses -fno-exceptions, which might save a few bytes (or, maybe, not, depending on whoknowswhat).

Unless, of course you need exceptions, in which case: nevermind. I mean, when I'm really concerned about code size and I think I might be approaching something like 80% of capacity, I tend to abandon some of my extravagant big-program practices like using exceptions. But that's just me.

As far as -fno-inline-small-functions, is this really needed to encourage the compiler to "do the right" thing here (assuming you have already given it -Os)?

My experience with other GNU compilers (mipsel-linux, arm-linux) is that the compiler out-optimizes, re-optimizes and optimizes the heck out of anything other than -Os that I have tried to "help" it with.

However, I am always interested in learning from other people's real-world experience. (I have always depended on the kindness of strangers.)

Regards,

Dave