Forum: Compiler & IDEs Laden des Hexfile in VMLab schlägt fehl.


von Tegs M. (tegsmax)


Lesenswert?

Hallo erstmal,

ich versuche das Projekt ETH_M32_EX 
(http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex), 
beziehungsweise die Software per VMLab zu testen. Habe die Platine 
bereits aufgebaut aber warte noch auf den Programmieradapter (danke 
DHL...).

Dem Projekt liegt ein kompletter makefile bei und das Erstellen per GCC 
klappt auch ohne Fehler.
Nun weigert sich VMLab aber den Hexfile zu laden und meldet:
"File webserver_mega32.hex contains code beyond implemented address in 
this micro"

Der Typ des Mikrokontrollers ist sowohl im makefile als auch in VMLab 
auf ATmega32 eingestellt.

Im Makefile findet sich ein Target namens "coff" mit dem Kommentar: "# 
Convert ELF to COFF for use in debugging / simulating in
# AVR Studio or VMLAB."

Das Target "all" sieht so aus:

# Default target.
all: begin gccversion sizebefore $(TARGET).elf $(TARGET).hex 
$(TARGET).eep \
  $(TARGET).lss $(TARGET).sym sizeafter finished end


Habe das Target "coff" mal in "all" eingebaut (vor "$(TARGET).hex"),
oder auch mal nach dem kompletten Build aufgerufen, aber ohne Erfolg.

Er scheint die coff Datei zu modifizieren aber VMLab beschwert sich 
trotzdem.

Habe zuerst die GCC-Toolchain in VMLab benutzt, aber auch mal die 
generische mit externem Aufruf von Make ausprobiert. Kein Erfolg, 
gleiche Meldung.

Die Direktive "COFF" habe ich in VMLab gesetzt, brigt auch nix.

Komme da nicht mehr weiter, weiß jemand einen Rat?

Viele Grüße,

tegsmax

von dummy (Gast)


Lesenswert?

>ich versuche das Projekt ETH_M32_EX
>(http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex),
>beziehungsweise die Software per VMLab zu testen.

Na da wünsch ich dir viel Spass den extern
angeschlossenen Ethernet Chip gleich mit zu simulieren.
Ohne den wird im Simulator wohl kaum was passieren.

von Tegs M. (tegsmax)


Lesenswert?

Schon klar das ich diese Funktionalität nicht nutzen kann,
darum geht es mir nicht.

Trotzdem danke für die "Hilfe" ... :-(

von Oliver (Gast)


Lesenswert?

Ich will dass jetzt nicht extra übersetzen, aber wenn VMLAB sagt, daß 
das Hexfile für den Prozessor zu groß ist, dann ist das meistens auch 
so.

Versuch mal eine ältere WinAVR-Version. Vielleicht wir der Code damit 
kleiner.

Oliver

von Tegs M. (tegsmax)


Lesenswert?

Werde ich mal versuchen.

Dachte es könnte daran liegen das die Modifikation der Dateien durch das 
Target "coff" vielleicht nicht die eigentliche Wirkung erzielt und die 
Meldung daher rührt.

Der entsprechende Part im Makefile sieht so aus:

# Convert ELF to COFF for use in debugging / simulating in
# AVR Studio or VMLAB.
COFFCONVERT=$(OBJCOPY) --debugging \
  --change-section-address .data-0x800000 \
  --change-section-address .bss-0x800000 \
  --change-section-address .noinit-0x800000 \
  --change-section-address .eeprom-0x810000


coff: $(TARGET).elf
  @echo
  @echo $(MSG_COFF) $(TARGET).cof
  $(COFFCONVERT) -O coff-avr $< $(TARGET).cof

Könnte es an der fehlenden Auswirkung dieser Kommandos liegen das das 
Hexfile zu groß wird?

von dummy (Gast)


Lesenswert?

>Könnte es an der fehlenden Auswirkung dieser Kommandos liegen das das
>Hexfile zu groß wird?

Nö, eher an fehlender Optimierung.
Oder am falschen Compiler wie ja schon gesagt wurde.
Poste mal die letzten zwei Zeilen aus dem
Hexfile. Nur mal um zu sehen bis wohin Code
erzeugt wird.

von Tegs M. (tegsmax)


Lesenswert?

:0A86CE0000000D0A0D0A00740400FC
:00000001FF


Im GCC Output steht:


Webserver_MEGA32.elf  :
section             size      addr
.text              34174         0
.data                346   8388704
.bss                1056   8389050
.debug_aranges       384         0
.debug_pubnames     7723         0
.debug_info        28642         0
.debug_abbrev       6057         0
.debug_line        14395         0
.debug_frame        1600         0
.debug_str          4011         0
.debug_loc          6697         0
.debug_ranges        288         0
Total             105373

von dummy (Gast)


Lesenswert?

>.text              34174         0

Das passt auch nicht mehr in einen ATMega32.
Bei 32767 (0x7FFF) ist Schluss.

Hab mir grad mal die Version 1.14 bei Ulrich gezogen
und compiliert. Hier die Adressen aus meinen HEX Files

AVR-GCC  4.1.2  0x7B9C  passt
ACR-GCC  4.3.0  0x843E  passt nicht

Gewaltiger Unterschied.
Compiliert mit dem gleichen makefile.

von Tegs M. (tegsmax)


Lesenswert?

Tatsächlich... mit Version 4.1.2 kommt bei mir folgendes heraus:

Webserver_MEGA32.elf  :
section             size      addr
.text              31308         0
.data                346   8388704
.bss                1056   8389050
.stab                888         0
.stabstr             113         0
.debug_aranges       384         0
.debug_pubnames     7723         0
.debug_info        28399         0
.debug_abbrev       5550         0
.debug_line        13721         0
.debug_frame        1600         0
.debug_str          4021         0
.debug_loc          5409         0
.debug_ranges         24         0
Total             100542

Meldung weg, Simulation läuft. Sehr schön ;-)   danke!

Nur noch eine kurze Frage:

Wo findest Du die Adressen aus deinen HEX Files die Du aufgelistet hast?
Der aktuelle endet bei mir z.B. so:

:107B7C0020202020202020202020202020000A004F
:107B8C0032001E0000000000000000000000000099
:0A7B9C0000000D0A0D0A0074040039
:00000001FF

von dummy (Gast)


Lesenswert?

>Wo findest Du die Adressen aus deinen HEX Files die Du aufgelistet hast?
>Der aktuelle endet bei mir z.B. so:

>:107B7C0020202020202020202020202020000A004F
>:107B8C0032001E0000000000000000000000000099
>:0A7B9C0000000D0A0D0A0074040039

:0A  "7B9C"  0000000D0A0D0A0074040039

Da steht sie. Ist nicht die letzte Adresse,
aber kurz davor ;)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.