AVR-Studio mit WinAVR erzeugt plötzlich falsches HEX-Format

[BlooD]

Moin zusammen.

Hab ein merkwürdiges Problem:
Versuche gerade eine Steuerung für Servos zu basteln und als ich irgendwas im Programm geändert hab erzeugt der Compiler plötzlich ein merkwürdiges HEX-Format.
Das Hex-File ist auch auf einmal 29kB groß und hatte vor der Änderung bis etwas mehr über die Hälfte in den ATMega16 gepasst.

Ich hab schon in den Einstellungen alles versucht umzustellen, hatte aber keinen Erfolg.

Leider weiß ich auch nicht mehr was ich genau geändert habe, habe jedenfalls ein bisschen aufgeräumt und funktionen nach oben bzw. unten verschoben.

Das jetztige Format:
https://www.roboternetz.de/phpBB2/files/pony1.png


Ein anderes Projekt compiliert richtig:
https://www.roboternetz.de/phpBB2/files/pony2.png


Hat jemand eine Idee, woran das liegen könnte?

[m.a.r.v.i.n]

Hi,

das sieht nach dem Intel Hex Format aus. Ein Textfile Format für Binärdaten.
Das Ausgabeformat wird im Makefile festgelegt. Schau mal nach ob da

--oformat=ihex
drint steht.
Näheres steht auch im RN Wiki:
https://www.roboternetz.de/wissen/index.php/Avr-gcc

Gruß m.a.r.v.i.n

[BlooD]

Nein, steht leider nicht drin...
Das Makefile, das von AVR-Studio erstellt wird beinhaltet folgendes:


################################################## #############################
# Makefile for the project Servo
################################################## #############################

## General Flags
PROJECT = Servo
MCU = atmega16
TARGET = Servo.elf
CC = avr-gcc.exe

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 -DF_CPU=8000000UL -O0 -fsigned-char
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS +=


## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0


## Objects that must be built in order to link
OBJECTS = Servo.o i2clcd.o twimaster.o

## Objects explicitly added by the user
LINKONLYOBJECTS =

## Build
all: $(TARGET) Servo.hex Servo.eep size

## Compile
Servo.o: ../Servo.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

i2clcd.o: ../i2clcd.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

twimaster.o: ../twimaster.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

##Link
$(TARGET): $(OBJECTS)
$(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)

%.hex: $(TARGET)
avr-objcopy -O ihex $(HEX_FLASH_FLAGS) $< $@

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

%.lss: $(TARGET)
avr-objdump -h -S $< > $@

size: ${TARGET}
@echo
@avr-size -C --mcu=${MCU} ${TARGET}

## Clean target
.PHONY: clean
clean:
-rm -rf $(OBJECTS) Servo.elf dep/* Servo.hex Servo.eep

## Other dependencies
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)




Das gleicht dem funktionierenden Project genau (bis auf das, dass hier 3 Source-Dateien zu behandeln sind)

[BlooD]

Also, wenn ich das Servo.elf durch


avr-objcopy -O binary Servo.elf Servo.hex

umwandle, siehts wieder normal aus, lässt sich mir Ponyprog übertragen und läuft :)

Aber was hab ich jetzt in AVRStudio verstellt, das er das im ihex format macht?
Vorallem ist das Makefile vom funktionierenden Projekt in dem Bereich identisch...

Idee?

[m.a.r.v.i.n]

Doch, ihex steht schon drin als Format. Das ist ja auch soweit ok. Ponyprog müßte beim Laden von einem Hex-File eigentlich wissen, das ein Intel Hexfile zu laden ist. Wie lädst du denn das File in Ponyprog?

Open Program (FLASH) File
Als Device Typ *.hex auswählen.
OK klicken.

Gruß m.a.r.v.i.n

Edit:

*.hex als Dateiendung für Intel Hex und Binärdatei zu verwenden, ist nicht so günstig. *.bin für Binärforamt wäre sinnvoller.

[BlooD]

Normalerweise lade ich das File mit nem Script.
Wenn ich das so öffne, wie du sagst, dann hab ich aber genau das gleiche Problem.

Also wenn ich dich richtig verstehe, dann sollte Ponyprog die Umwandlung ins binäre Format selber machen?

Was mir auch noch auffällt:
Bei allen anderen Projekten sind die .hex-Files kleiner (ca. um den Faktor 3), als die .elf-Files. Nur bei diesem Projekt nicht, deshalb denke ich schon das es an AVRStudio liegt.

[m.a.r.v.i.n]

Das kann ich nicht nachvollziehen.
Lade ich ein Intel Hex File unter Ponyprog, wie oben beschrieben, dann wird dies korrekt konvertiert. Ich kann es dann auch binär speichern.

Save Program File as
Als Device Typ *.bin angeben
OK klicken.

Selbst wenn ich das Binärfile in *.hex oder ein Intel Hex File in *.bin umbenenne und lade, wird es immer korrekt konvertiert.

Welche ponyprog Version verwendest du? 2.06fBETA

Das elf File ist bei mir mehr als 10x größer als das Hex File. (evtl wg. Degug Optionen)

Gruß m.a.r.v.i.n

[BlooD]

Ich hatte noch die Vorgängerversion.
Nach dem Update auf die 2.06fBETA funktioniert es :)

Ich wusste nicht, das Ponyprog automatsich konvertieren kann...

Es ist zwar immernoch merkwürdig, dass das AVR-Studio manchmal iHEX und manchmal das BIN-Format macht, aber so krieg ichs wenigstens gebrannt :)

--> DANKE!

[SprinterSB]

Warum sagst du -O binary, wenn du ihex willst...? Evtl musst du sagen, welche Sections du im hex haben willst (hex ist zu dumm um Sections zu kennen). Das ich wichtig, demit eeprom-Info nicht ins Flash kommt und debug-Infos und so gefiltert werden.

Hier ein Makefile-Snipp, machs analog

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

%_eeprom.hex: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@

avr-objcopy

[H.A.R.R.Y.]

Sehr interessant die Bemerkung zum Hex.

Ich habe leider auch noch ein ungelöstes Problem und weiß nicht genau wo ich suchen muß:
Ich benutze WinAVR für die C-Programmierung, AVR-Studio für die Simulation. Für ein Bootlader-Experiment möchte ich im ATmega168 den Code auf 0x1c00 festnageln. Das geht nur leider schief. Aso der Reihe nach:
Mein makefile sieht so aus:

PRG = bootload
OBJ = bootload.c
MCU_TARGET = atmega168
OPTIMIZE = -O2

DEFS =
LIBS = -lm

# You should not have to change anything below here.

CC = avr-gcc

# Override is only needed by avr-lib build system.

override CFLAGS = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS)
override LDFLAGS = -Wl,--section-start=.bootloader=0x1c00,-Map,$(PRG).map

OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump

all: $(PRG).elf lst text eeprom

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

clean:
rm -rf *.o $(PRG).elf *.eps *.png *.pdf *.bak
rm -rf *.lst *.map $(EXTRA_CLEAN_FILES)

lst: $(PRG).lst

%.lst: %.elf
$(OBJDUMP) -h -S $< > $@

# Rules for building the .text rom images

text: hex bin srec

hex: $(PRG).hex
bin: $(PRG).bin
srec: $(PRG).srec

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

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

%.bin: %.elf
$(OBJCOPY) -j .text -j .data -O binary $< $@

# Rules for building the .eeprom rom images

eeprom: ehex ebin esrec

ehex: $(PRG)_eeprom.hex
ebin: $(PRG)_eeprom.bin
esrec: $(PRG)_eeprom.srec

%_eeprom.hex: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@

%_eeprom.srec: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O srec $< $@

%_eeprom.bin: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O binary $< $@

# Every thing below here is used by avr-libc's build system and can be ignored
# by the casual user.

FIG2DEV = fig2dev
EXTRA_CLEAN_FILES = *.hex *.bin *.srec

dox: eps png pdf

eps: $(PRG).eps
png: $(PRG).png
pdf: $(PRG).pdf

%.eps: %.fig
$(FIG2DEV) -L eps $< $@

%.pdf: %.fig
$(FIG2DEV) -L pdf $< $@

%.png: %.fig
$(FIG2DEV) -L png $< $@



Im C-Code ist <avr/boot.h> eingebunden und die Funktionen haben alle ihren Prototyp gemäß WinAVR-Doku:

// function prototypes that go into the bootloader section
void wait1sec () __attribute__ ((section (".bootloader")));
char getChar () __attribute__ ((section (".bootloader")));
void putChar (char data) __attribute__ ((section (".bootloader")));
void sendString (char *string) __attribute__ ((section (".bootloader")));
void sendTheBuffer (int size) __attribute__ ((section (".bootloader")));
void receiveTheBuffer (int size) __attribute__ ((section (".bootloader")));
void xAbort () __attribute__ ((section (".bootloader")));
char xCalcSum(char *data) __attribute__ ((section (".bootloader")));
int xCalcCrc(char *data) __attribute__ ((section (".bootloader")));
void xSendPacket(char packetNum, char *data, char checkMethod) __attribute__ ((section (".bootloader")));
char xReceivePacket (char checkMethod) __attribute__ ((section (".bootloader")));
char receivePackets (char checkMethod) __attribute__ ((section (".bootloader")));
char sendPackets(int packets, char checkMethod) __attribute__ ((section (".bootloader")));
int main (void) BOOTLOADER_SECTION;//__attribute__ ((section (".bootloader")));

Bei der Übersetzung gibt es eine Warnung, weil bei diesem Controller die eeprom.h nicht funktioniert, aber das benutze ich hier auch nicht, also ignorieren.

Das erzeugte Map-File sieht auch noch vertrauenerweckend aus (besonders die letzten Zeilen):

Archive member included because of file (symbol)

C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_copy_data.o)
C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o (__do_copy_data)
C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_clear_bss.o)
C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o (__do_clear_bss)

Allocating common symbols
Common symbol size file

xPacketBuffer 0x85 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o

Memory Configuration

Name Origin Length Attributes
text 0x00000000 0x00020000 xr
data 0x00800060 0x0000ffa0 rw !x
eeprom 0x00810000 0x00010000 rw !x
*default* 0x00000000 0xffffffff

Linker script and memory map

Address of section .data set to 0x800100
LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o
Address of section .bootloader set to 0x1c00
LOAD C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o
LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5\libm.a
LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a
LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5\libc.a
LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a

.hash
*(.hash)

.dynsym
*(.dynsym)

.dynstr
*(.dynstr)

.gnu.version
*(.gnu.version)

.gnu.version_d
*(.gnu.version_d)

.gnu.version_r
*(.gnu.version_r)

.rel.init
*(.rel.init)

.rela.init
*(.rela.init)

.rel.text
*(.rel.text)
*(.rel.text.*)
*(.rel.gnu.linkonce.t*)

.rela.text
*(.rela.text)
*(.rela.text.*)
*(.rela.gnu.linkonce.t*)

.rel.fini
*(.rel.fini)

.rela.fini
*(.rela.fini)

.rel.rodata
*(.rel.rodata)
*(.rel.rodata.*)
*(.rel.gnu.linkonce.r*)

.rela.rodata
*(.rela.rodata)
*(.rela.rodata.*)
*(.rela.gnu.linkonce.r*)

.rel.data
*(.rel.data)
*(.rel.data.*)
*(.rel.gnu.linkonce.d*)

.rela.data
*(.rela.data)
*(.rela.data.*)
*(.rela.gnu.linkonce.d*)

.rel.ctors
*(.rel.ctors)

.rela.ctors
*(.rela.ctors)

.rel.dtors
*(.rel.dtors)

.rela.dtors
*(.rela.dtors)

.rel.got
*(.rel.got)

.rela.got
*(.rela.got)

.rel.bss
*(.rel.bss)

.rela.bss
*(.rela.bss)

.rel.plt
*(.rel.plt)

.rela.plt
*(.rela.plt)

.text 0x00000000 0xa2
*(.vectors)
.vectors 0x00000000 0x68 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o
0x00000000 __vectors
0x00000000 __vector_default
0x00000068 __ctors_start = .
*(.ctors)
0x00000068 __ctors_end = .
0x00000068 __dtors_start = .
*(.dtors)
0x00000068 __dtors_end = .
*(.progmem.gcc*)
*(.progmem*)
0x00000068 . = ALIGN (0x2)
*(.init0)
*(.init1)
*(.init2)
.init2 0x00000068 0xc C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o
*(.init3)
*(.init4)
.init4 0x00000074 0x16 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_copy_data.o)
0x00000074 __do_copy_data
.init4 0x0000008a 0x10 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_clear_bss.o)
0x0000008a __do_clear_bss
*(.init5)
*(.init6)
*(.init7)
*(.init8)
*(.init9)
.init9 0x0000009a 0x4 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o
*(.text)
.text 0x0000009e 0x4 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o
0x0000009e __vector_22
0x0000009e __vector_1
0x0000009e __vector_24
0x0000009e __vector_12
0x0000009e __bad_interrupt
0x0000009e __vector_6
0x0000009e __vector_3
0x0000009e __vector_23
0x0000009e __vector_25
0x0000009e __vector_11
0x0000009e __vector_13
0x0000009e __vector_17
0x0000009e __vector_19
0x0000009e __vector_7
0x0000009e __vector_5
0x0000009e __vector_4
0x0000009e __vector_9
0x0000009e __vector_2
0x0000009e __vector_21
0x0000009e __vector_15
0x0000009e __vector_8
0x0000009e __vector_14
0x0000009e __vector_10
0x0000009e __vector_16
0x0000009e __vector_18
0x0000009e __vector_20
0x000000a2 . = ALIGN (0x2)
*(.text.*)
0x000000a2 . = ALIGN (0x2)
*(.fini9)
*(.fini8)
*(.fini7)
*(.fini6)
*(.fini5)
*(.fini4)
*(.fini3)
*(.fini2)
*(.fini1)
*(.fini0)
0x000000a2 _etext = .

.data 0x00800100 0x146 load address 0x000000a2
0x00800100 PROVIDE (__data_start, .)
*(.data)
.data 0x00800100 0x146 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o
*(.gnu.linkonce.d*)
0x00800246 . = ALIGN (0x2)
0x00800246 _edata = .
0x00800246 PROVIDE (__data_end, .)

.bss 0x00800246 0x85
0x00800246 PROVIDE (__bss_start, .)
*(.bss)
*(COMMON)
COMMON 0x00800246 0x85 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o
0x0 (size before relaxing)
0x00800246 xPacketBuffer
0x008002cb PROVIDE (__bss_end, .)
0x000000a2 __data_load_start = LOADADDR (.data)
0x000001e8 __data_load_end = (__data_load_start + SIZEOF (.data))

.noinit 0x008002cb 0x0
0x008002cb PROVIDE (__noinit_start, .)
*(.noinit*)
0x008002cb PROVIDE (__noinit_end, .)
0x008002cb _end = .
0x008002cb PROVIDE (__heap_start, .)

.eeprom 0x00810000 0x0
*(.eeprom*)
0x00810000 __eeprom_end = .

.stab
*(.stab)

.stabstr
*(.stabstr)

.stab.excl
*(.stab.excl)

.stab.exclstr
*(.stab.exclstr)

.stab.index
*(.stab.index)

.stab.indexstr
*(.stab.indexstr)

.comment
*(.comment)

.debug
*(.debug)

.line
*(.line)

.debug_srcinfo
*(.debug_srcinfo)

.debug_sfnames
*(.debug_sfnames)

.debug_aranges 0x00000000 0x4c
*(.debug_aranges)
.debug_aranges
0x00000000 0x4c C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o

.debug_pubnames
0x00000000 0xf3
*(.debug_pubnames)
.debug_pubnames
0x00000000 0xf3 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o

.debug_info 0x00000000 0x59e
*(.debug_info)
.debug_info 0x00000000 0x59e C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o
*(.gnu.linkonce.wi.*)

.debug_abbrev 0x00000000 0x1b2
*(.debug_abbrev)
.debug_abbrev 0x00000000 0x1b2 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o

.debug_line 0x00000000 0x529
*(.debug_line)
.debug_line 0x00000000 0x529 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o

.debug_frame
*(.debug_frame)

.debug_str 0x00000000 0x24e
*(.debug_str)
.debug_str 0x00000000 0x24e C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o
0x292 (size before relaxing)

.debug_loc
*(.debug_loc)

.debug_macinfo
*(.debug_macinfo)
OUTPUT(bootload.elf elf32-avr)

.bootloader 0x00001c00 0x47c
.bootloader 0x00001c00 0x47c C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o
0x00001c00 wait1sec
0x00001cdc xCalcSum
0x00001dae xReceivePacket
0x00001e5c receivePackets
0x00001c70 sendTheBuffer
0x00001ec6 sendPackets
0x00001c36 putChar
0x00001f20 main
0x00001cfc xCalcCrc
0x00001d4c xSendPacket
0x00001cc8 xAbort
0x00001c46 sendString
0x00001c20 getChar
0x00001c9c receiveTheBuffer

Bis hierher haben die Tools verstanden was ich von Ihnen will. Die Adresslage paßt noch.

Das Hex-file steht dann aber "daneben":

:100000000C9434000C944F000C944F000C944F004F
:100010000C944F000C944F000C944F000C944F0024
:100020000C944F000C944F000C944F000C944F0014
:100030000C944F000C944F000C944F000C944F0004
:100040000C944F000C944F000C944F000C944F00F4
:100050000C944F000C944F000C944F000C944F00E4
:100060000C944F000C944F0011241FBECFEFD4E02E
:10007000DEBFCDBF12E0A0E0B1E0E2EAF0E002C0F6
:1000800005900D92A634B107D9F712E0A6E4B2E0CC
:1000900001C01D92AB3CB107E1F70C94900F0C949A
:0200A00000005E
:1000A2000D0A582D4D4F44454D20746573740D0A49
:1000B200747970652027722720746F2072656365DA
:1000C20069766520646174612066726F6D206F725B
:1000D2002027732720746F2073656E642064617417
:1000E2006120746F207465726D696E616C0D0A0017
:1000F2000D0A3E003A20756E6B6E6F776E20636F4D
:100102006D6D616E6400202D3E2072656164792000
:10011200746F20726563656976652C2077616974F6
:10012200696E6720666F722064617461207061631A
:100132006B65747300202D2063616E63656C6C6562
:1001420064202873657276657220646964206E6F1C
:100152007420726573706F6E642077697468696E5B
:1001620020313230732900202D3E2072656164797E
:1001720020746F2073656E642C2077616974696ED8
:100182006720666F72207265717565737400202D29
:10019200207472616E736D697373696F6E20636F21
:1001A2006D706C6574656400202D207472616E73CD
:1001B2006D697373696F6E2061626F72746564003A
:1001C200202D207472616E736D697373696F6E2076
:1001D20061626F727465642064756520746F206556
:0601E20072726F727300DF
:00000001FF

Alles ist wie immer ab Adresse 0x0000 referenziert, auch AVR-Studio zeigt mir in der Simulation Nonsens in der falschen Adresslage an (die Bootreset-Option habe ich auf 0x1c00 eingestellt). Also scheint es am Generator für die Hex-Files / makfile zu liegen. Aber wo?

Muß ich dem Hex-File-Generator (avr-objcopy?) noch etwas im makefile mitteilen? Wenn ja was und wie? In der Doku (zu WinAVR) habe ich es noch nicht gefunden.

Bevor sich jetzt jemand wundert: Dies ist bisher irgendein Programm, das im Bereich des Bootloaders residieren soll, ohne SPM und alles. Erst wenn das stimmt, gehe ich an die Entwicklung des eigentlichen Bootladers...

[m.a.r.v.i.n]

Hi H.A.R.R.Y,

warum änderst du nicht einfach die Startadresse des .text Segment, statt ein neues zu erfinden. Außerdem müßte für den mega168 der Bootloader bei Adresse 0x3800 beginnen.


--section-start=.text=0x3800

Oder guck dir mal an, wie das beim chip45 Bootloader gemacht ist:
http://www.chip45.com/index.pl?page=chip45boot&lang=de

Gruß m.a.r.v.i.n

[SprinterSB]

Bei erzeugen des Hex machst du eigene HEX für jedes Modul (.text, .bootloader, .eerom)

%_bootloader.hex: %.elf
$(OBJCOPY) -j .bootloader --change-section-lma .bootloader=0x1c00 -O ihex $< $@

Falls objcopy keine hex-Zahlen frisst, musst die 0x1c00 eben noch nach dezimal umrechnen.

Die Startadressen für die Lokatierungen findest du im linker description file.

[H.A.R.R.Y.]

Hi, ich wußte doch das hier professionelle Hilfe geboten wird :D

Okay, Danke Euch, ich versuche mal beide Varianten.

Bei der Option das .text-Segment komplett zu verschieben habe ich auch die komplette IRQ-Tabelle und jede Menge anderen Init-Code vom Compiler mit drin. VORTEIL: Abgesehen von der Startadresse ist alles "wie gewohnt". ABER: es gibt so ein paar "Härtefälle" in denen die absolute minimal-Init (IRQs aus, Stackpointer=RAMTOP und ein zwei Register für den Compiler) vollkommen ausreicht, der Rest steht mit für's Programm zur Verfügung. Dazu muß ich halt sehr genau wissen, was ich da treibe sonst hakt es später im compilierten Programm. Sehe ich das richtig? Über die Frage "guter Programmierstil" möchte ich hier jetzt bitte nicht diskutieren, es geht ums Verständnis.

Die 0x3800: Laut Doku wird im FLASH mit Wortadressen gerechnet? Naja, das ist aber glaub ich die geringste Schwierigkeit. Ich seh ja im Simulator wohin der mir den Code packt.

Danke auch für das Syntax-Beispiel, jetzt ist der Groschen gefallen ("... ah jetzt ja!") :idea:

Eine Frage hät' ich noch: Wie heißt so ein Linker Description File typischwerweise und wo kann ich es finden (im WinAVR-Verzeichnisbaum, GROBE Angabe reicht mir schon)? Reicht ein ordinärer Texteditor (notepad, xemacs, ...) zum ansehen? Falls nicht, welches Tool benötige ich dazu?

DANKE und Gruß
H.A.R.R.Y.

[SprinterSB]

Eine Frage hät' ich noch: Wie heißt so ein Linker Description File typischwerweise und wo kann ich es finden (im WinAVR-Verzeichnisbaum, GROBE Angabe reicht mir schon)?

https://www.roboternetz.de/wissen/index.php/WinAVR#Verzeichnisbaum

Abhängig von den Linker-Flags wird ein anderes ld-Skript genommen (*.x, *.xb) aber frag mich jetzt nicht, was die Endungen bedeuten und wann welche genommen wird.

Vielleicht mal die specs befragen (welche genommen werden siehst du mit avr-gcc -v ...)

AFAIK kannst du auch einfach ein ld-Skript dazulinken. Alles, was kein elf32-avr ist, wird als ld-Skript interpretiert.

Ob die Lokatierungen stimmen siehst du im Mapfile.

Da IHEX keine Sektion-Information trägt (bzw alles in eine große Sektion gestopft wird) muss die lma (load memory address) für jeden Code-Block (.eeprom, ...) angegeben werden.


Reicht ein ordinärer Texteditor (notepad, xemacs, ...) zum ansehen? Falls nicht, welches Tool benötige ich dazu?
Ein Skript ist ein Skript und damit plain text.

(x)emacs ist kein Editor, sonder ein Betriebssystem. Bzw wäre ein Betriebbsystem, wenn ein guter Editor dabei wäre ;-)

[H.A.R.R.Y.]

Feine Erklärung. Damit komme ich zurecht.
Danke

Gruß H.A.R.R.Y.