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
Einen Bootloader schreibt man mit Vorteil in ASM, und dann sind die push und pop genau da wo du sie haben moechtest.
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
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
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/*)
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
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.