Forum: Compiler & IDEs kein Rücksprung aus Funktionen in NRWW section?


von Holger (Gast)


Lesenswert?

Hallo,

bin gerade etwas am Verzweifeln... Ich will einen bootloader schreiben. 
Daher hab ich den boot reset vector gesetzt und an dieser Adresse spring 
ich entweder in die main oder mach ein update. Den NRWW Bereich hab ich 
in zwei Bereiche unterteilt. Der eine beginnt liegt am Anfang der 
bootloader section und wird nach einem reset angesprungen. In dem 
anderen Bereich sind die eigentlichen Funktionen zum Löschen und 
Schreiben der einzlnen RWW pages. Dies musste ich so machen, da auch aus 
der main ein Aufruf des bootloader möglich sein soll. Nun hab ich aber 
festegestellt, dass die Funktionen in einem NRWW keine Push/pops 
enthalten, wenn ich das Programm compiliere. Das heißt, wenn ich eine 
dieser Funktionen aufrufe springt das Programm irgenwo in den Wald? Kann 
man über Compiler settings dies ändern? Oder mach ich irgendwas falsch?

Vielen Dank im Vorraus!

MfG,

Holger

von Nealpotter (Gast)


Lesenswert?

Einen Bootloader schreibt man mit Vorteil in ASM, und dann sind die push 
und pop genau da wo du sie haben moechtest.

von kosmonaut_pirx (Gast)


Lesenswert?

hallo,
so ganz verstehe ich das problem der zwei-teilung der nrww nicht. du 
kannst doch genau so gut an den beginn der nrww springen, und da dort 
auch die BLS beginnen lassen. oder irre ich da?

aber gehen wir mal davon aus, die adresse ist vorgegeben. dann zeig mal 
bitte her bitte, wie du kompilierst und linkst.
bye kosmo

von Peter D. (peda)


Lesenswert?

Ich würde API-Funktionen komplett in Assembler schreiben und als 
Einsprungpunkt die letze Flashadresse nehmen.


Wenn man sich mal Bootloader in C näher anschaut, ist das eigentlich nur 
ne Aneinanderreihung von Assembler-Macros, also irgendwie schon durch 
die Brust ins Auge.


Peter

von Holger (Gast)


Lesenswert?

Hallo,

Das mit der Unterteilung der NRWW sections hab ich gemacht, damit meine 
Startfunction immer an der Adresse vom boot reset vector liegt. Damit 
hat es aber, glaube ich, weniger zu tun. Wenn ich das ändere und nur 
eine NRWW section nehme, sind nach dem compilieren auch keine push/pops 
in der lss-Datei zu sehen. Vielleicht gibt es irgendwelche compiler 
flags, um dies bei Funktionen im NRWW Bereich zu aktivieren. Im 
folgenden mal das makefile.


## General Flags
PROJECT = ir2ps2
MCU = atmega32
TARGET = ir2ps2.elf
CC = avr-gcc

## 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=8000000  -Os  -fsigned-char
CFLAGS += -Wp,-M,-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 += -minit-stack=0x800  -Wl,-Map=ir2ps2.map
LDFLAGS += -Wl,-section-start=.bootloader=0x7e00
LDFLAGS += -Wl,-section-start=.bootcode=0x7000
LDFLAGS += -Wl,-section-start=.finit9=0x6fd0


## 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


## Include Directories
INCLUDES = -I"C:\winavr\test."

## Objects that must be built in order to link
OBJECTS = ir2ps2.o keyboard.o

## Build
all: $(TARGET) ir2ps2.hex ir2ps2.eep ir2ps2.lss

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

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

##Link
$(TARGET): $(OBJECTS)
   $(CC) $(LDFLAGS) $(OBJECTS) $(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 $< > $@

## Clean target
.PHONY: clean
clean:
  -rm -rf $(OBJECTS) ir2ps2.elf dep/ ir2ps2.hex ir2ps2.eep ir2ps2.lss 
ir2ps2.map


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

von Peter D. (peda)


Lesenswert?

kosmonaut_pirx wrote:
> hallo,
> so ganz verstehe ich das problem der zwei-teilung der nrww nicht. du
> kannst doch genau so gut an den beginn der nrww springen, und da dort
> auch die BLS beginnen lassen. oder irre ich da?


Den API-Call an den Bootloaderstart zu legen, hätte das Problem, wie der 
Bootloader dann zweifelsfrei erkennen kann, ob es ein Reset oder eben 
ein API-Call ist.

Außerdem gibt es ja 4 Möglichkeiten, wo der Bootstart liegen kann.


Peter

von kosmonaut pirx (Gast)


Lesenswert?

hallo,

>Den API-Call an den Bootloaderstart zu legen, hätte das Problem, wie der
>Bootloader dann zweifelsfrei erkennen kann, ob es ein Reset oder eben
>ein API-Call ist

da biete das reset-register hilfreiche dienste. so denn keine runtime 
oder irgendwr anders böses das schon geclear-ed hat.

>Außerdem gibt es ja 4 Möglichkeiten, wo der Bootstart liegen kann

das ist richtig.
die kann man meines wissens nach aber nur von aussen ändern. somit ist 
es auch kein problem, im gleichem atemzug den richtigen wert zu setzen.

@OP: der gcc und der linker wissen rein gar nichts von irgendwelchen 
NRWW-sections. der code ist daher exakt der gleiche (der selbe?) wie für 
andere speicherbereiche. ich kann nur vermuten, dass deine 
schreib-routinen lediglich die macros aus der boot.h sind. keine ahnung, 
ob das geht, nur so eine idee.

bye kosmo

von Realpotter (Gast)


Lesenswert?

Wozu braucht's denn die push/pops ? Zum rumspringen brauchts die nicht, 
denn das ist mit rjmp, rcall & ret getan. (Funktions-)Parameter ? 
Muessen nicht auf'm Stack sein. Ist der Stack denn ueberhaupt schon 
definiert ?

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.