simulavr error: address out of bounds bei Initialisierung SPH

[Ulf R. (roolf)]

Hallo,

ich begehe gerade meine ersten Schritte mit der AVR-Programmierung; Ziel 
ist ein reines Assemblerprogramm unter Debian Linux mit der gcc 
toolchain zu erstellen und auch zu simulieren.

Programm first.S

#include <avr/io.h>
#define temp r19

  .org 0
  
  ldi temp, lo8(RAMEND)
  out _SFR_IO_ADDR(SPL), temp
  ldi temp, hi8(RAMEND)
  out _SFR_IO_ADDR(SPH), temp

go:  
  rjmp go

wird (durch ein Standard-Makefile) übersetzt mit

avr-gcc -c -mmcu=atmega8 -I. -x assembler-with-cpp \
  -Wa,-adhlns=obj/first.lst,-gstabs first.S -o obj/first.o
avr-gcc -mmcu=atmega8 -I. -gstabs -DF_CPU=14745600UL \
  -Os -funsigned-char -funsigned-bitfields -fpack-struct \
  -fshort-enums -Wall -Wstrict-prototypes -Wundef \
  -Wa,-adhlns=obj/first.o  -std=gnu99 --combine -fwhole-program \
  -Wundef -MD -MP -MF .dep/first.elf.d obj/first.o \
  --output first.elf -Wl,-Map=first.map,--cref  -nostdlib
avr-objcopy -O ihex -R .eeprom first.elf first.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
  --change-section-lma .eeprom=0 -O ihex first.elf first.eep

Nun ist simulavr in der Version 0.1.2.6 (von 
http://mirror.its.uidaho.edu/pub/savannah/simulavr/) installiert. Die 
Simulation (avr-gdb 6.4) wird gestartet mit

simulavr --gdbserver --device atmega8 \
        --clock-freq 14745600 --port 4242 &

avr-gdb

und dort eingegeben

file first.elf
target remote localhost:4242
load
s

und mehrfach RETURN zur Einzelschrittsimulation. Es kommt nach einigen 
Schritten zu folgender Fehlermeldung:

(gdb) s
42              out _SFR_IO_ADDR(SPL), temp
(gdb)
reset () at first.S:43
43              ldi temp, hi8(RAMEND)
(gdb)
44              out _SFR_IO_ADDR(SPH), temp
(gdb)

storage.h:58: ERROR: address out of bounds: 0x460

Ignoring packet error, continuing...

Das Disassembler-File first.lss zeigt

reset:
        ldi temp, lo8(RAMEND)
   0:   3f e5           ldi     r19, 0x5F       ; 95
        out _SFR_IO_ADDR(SPL), temp
   2:   3d bf           out     0x3d, r19       ; 61
        ldi temp, hi8(RAMEND)
   4:   34 e0           ldi     r19, 0x04       ; 4
        out _SFR_IO_ADDR(SPH), temp
   6:   3e bf           out     0x3e, r19       ; 62

d.h. der Stackpointer wird offenbar mit 0x045f geladen, was bei 1kB RAM 
und 0x20 für Register und weiteren 0x40 für IO-Register wie erwartet 
ist. Woher kommt dann der obige fehlerhafte Zugriff auf 0x0460?

[Ulf R. (roolf)]

Fürs Archiv: Ich konnte das Problem lösen. Ursache war offenbar eine 
Verwirrung der gcc-Toolchain durch verschiedene inkompatible Optionen 
(?); meine Aufrufe oben stammten aus einem zusammengegoogelten Makefile.

Der folgende Aufruf

avr-cpp -mmcu=atmega8 -o first.s first.S
avr-as -mmcu=atmega8 --warn --gstabs -o first.o first.s
avr-ld -nostdlib -o first.elf first.o

funktioniert bei mir und führt nun beim Paar simulavr/avr-gdb zum 
erwarteten Ergebnis.

[Jörg W. (dl8dtl) (Moderator)]

Ist aber immer noch nicht völlig korrekt.  Der avr-ld benötigt
ggf. noch ein -mavrX (X = 1...6).  Klappt für den ATmega8 gerade
nur zufällig mit dem Defaultwert.

[Ulf R. (roolf)]

Danke für den Hinweis auf das fehlende -mavrN bei avr-ld.

Offenbar ist es ziemlich ungewöhnlich, auf den AVR Mikrocontrollern in 
Assembler zu entwickeln - solche zusammenfassenden Informationen zum 
Thema "Reines Assemblerprojekt auf AVR unter Linux" habe ich in den 
einschlägigen Tutorials bisher nur sehr wenige gefunden.

[Jörg W. (dl8dtl) (Moderator)]

Ulf Rolf schrieb:

> Offenbar ist es ziemlich ungewöhnlich, auf den AVR Mikrocontrollern in
> Assembler zu entwickeln

Es gibt sicher ein paar Hanseln, die das tun, aber die werden dann
wohl allesamt den Primitiv-Assembler von Atmel benutzen, der ins
AVR Studio intrigiert ist.

Selbst mit der GNU Toolchain würde ich wohl persönlich alles dem
Frontend namens avr-gcc überlassen.  Mit einer Dateiendung .S ruft
es automatisch Präprozessor und Assembler auf, und es kann auch den
Linker selbst aufrufen.

[Ulf R. (roolf)]

Jörg Wunsch schrieb:

> Selbst mit der GNU Toolchain würde ich wohl persönlich alles dem
> Frontend namens avr-gcc überlassen.  Mit einer Dateiendung .S ruft
> es automatisch Präprozessor und Assembler auf, und es kann auch den
> Linker selbst aufrufen.

Das hatte ich zuerst versucht, allerdings beim Linken mit avr-gcc den 
Fehler "ldscripts/avr4.x: no such file or directory" erhalten. Mit 
obigem "avr-ld -mavr4 ..." bekomme ich jetzt denselben Fehler. Nach 
einigem Suchen habe ich nun herausgefunden, dass ich das Problem umgehen 
kann, wenn ich dem Linker "-L/usr/lib" als weitere Option mitgebe.

Bleibt die Frage, ob der Weg, Präprozessor, Compiler und Linker alles 
über avr-gcc aufzurufen, gleichwertig ist oder gar Vorteile bietet? Vom 
ästhetischen Programmierer-Gefühl her erscheint mir die 
Parameterübergabe in der Form "-Wa,..." bzw. "-Wl,..." einfach 
unsauberer als ein direkter Aufruf von avr-as bzw. avr-ld.