Hey,
ich möchte auf einem NXP LPC1768 das FreeRTOS Betriebssystem zum Laufen
bekommen. Ich arbeite mit Sourcery G++ Lite und Eclipse.
Meine erste Inbetriebnahme des Microcontrollers habe ich ohne FreeRTOS
durchgeführt, um einfach mal Startup- und Linker-Files auf Funktion zu
testen (da ich bisher keine Erfahrung damit habe). Habe also ein
einfaches LED-blinky mittels Timer geschreiben und die UART0 in Betrieb
genommen. Das hat alles soweit ohne Probleme funktioniert.
Nun wollte ich wie gesagt FreeRTOS integrieren. Es gibt ja einige
Demoprogramme vom Betriebssystemhersteller selbst. Ich habe aber kein
Rowly oder RedSuit Board. Deswegen habe ich dieses Demoprojekt von
FreeRTOS dahingehend verändert, dass es nur 2 Tasks gibt, die jeweils
eine LED mit unterschiedlicher Frequenz blinken lassen (bzw. einen GPIO
Pin toggln). Das Problem ist, dass immer sobald das Betriebssystem
übernehmen soll, nämlich nach dem SVC Call in den Hard Fault Handler
gesprungen wird. Normalerweise sollte ja der SVC Handler ausgeführt
werden, oder? Ich habe gelesen, dass angeblich 8 Registerwerte auf den
Stack gepusht werden, im Falle eines Hard Faults? Aber ich kann nirgends
finden wie ich diese Registerwerte interpretieren kann. Könnt ihr mir
weiterhelfen?
Mit freundlichen Grüßen
peter
freeRTOS benutzt und initialisiert den Cortex-M3 Systick-Handler. Ist
das im Startupcode richtig gesetzt? Das passiert bei mir im
cr_startup_lpc176x.c und sieht so aus:
Hey,
danke erstmal für die Antwort. Ich denke schon, dass der SysTickHandler
richtig gesetzt ist.
Habe es bisher mit 2 Varianten versucht. Zuerst mit einem Startupfile,
das ich über Google gefunden und angepasst habe und dann mit dem, was
FreeRTOS in dem Demoprojekt für das RedSuit-Board verwendet (beide
Varianten scheitern beim SVC Call). Aber ich arbeite jetzt mit den im
Anhang befindlichen Startup- und Linkerfiles.
Mit freundlichen Grüßen
peter
Hey,
ich habe mir heute mal im HardFault Handler die CFSR und HFSR
Registerwerte ausgeben lassen:
HFSR ist 0x4000 0000, also ein forced HardFault. Ist auch irgendwie
klar, weil eigentlich sollte ja in den SVCHandler gesprungen werden.
Doch das Interesante ist, das der Inhalt von CFSR 0x0 ist. Also kann ich
über diese Register auch den Fehler nicht eingrenzen.
Hat vielleicht jemand eine Idee woran das liegen kann, dass beim SVC
Call in den HardFault Handler gesprungen wird?
MfG. peter
Hey,
ok, und wieviel wäre dann Deiner Meinung nach sinnvoll? Habe das
Startupfile wie gesagt so gefunden und nur die Funktions- und
Variablennamen angepasst.
Mit freundlichen Grüßen
Peter
>ok, und wieviel wäre dann Deiner Meinung nach sinnvoll?
Unter 1kB würde ich da gar nicht erst anfangen.
> Habe das Startupfile wie gesagt so gefunden und nur die Funktions- und>Variablennamen angepasst.
Scheinbar aber nicht konseqent:
.weak PendSV_Handler
.type PendSV_Handler, %function
PendSV_Handler:
B .
.size PendSV_Handler, . - PendSV_Handler
Keine Ahnung ob das was ausmacht, aber ich würde mal in
das Assembler Listing File vom Compiler schauen ob da auch
die entsprechenden Funktionen von FreeRTOS benutzt werden.
Ein komplettes Projekt mit deinem Minimalbeispiel könnte
auch helfen hier nicht mehr im Nebel zu stochern.
Hallo,
ich habe hier mal ein Projekt für den LPC1769 drangehängt mit einem
simplen Demo. Ist aber makefile basierend. Die drei buildxx.bat sind zum
Übersetzen unter LPCXpresso (CodeRed), codesourcery lite und yagarto.
Ich probiere so immer mal was die (leicht) verschiedenen Compiler so
daraus machen. Hier ist der Startup mit Dateien aus dem CMSIS sowie dem
etwas geänderten Startup aus dem LPCXpresso. Es wird immer die newlib
verwendet und auch cpp ist möglich.
Eventuell bringt es dir was. Die Pfade in der buildxx.bat sind
anzupassen und im Tools-Verzeichnis sind ein paar binaries aus den
yagarto-tools die bei codesoucery fehlen.
Hoffe das hilft. Die 2. Ram-Bank vom LPC1768 steht übrigens in deinem
Link-Script auch nicht drin.
Hey,
aha. Problem ist, wie im ersten Post erwähnt ich kenn mich mit
Startupfiles nicht wirklich aus. Ich habe jetzt das Sartupfile
dahingehend verändert, dass in den Handlern auf die FreeRTOS Handler
verzweigt wird?
Im Anhang wie ich es gelöst habe. Aber offensichtlich habe ich es falsch
gelöst, denn es wird immer noch ein HardFault ausgelöst.
Mit freundlichen Grüßen
peter
Hey,
Entschuldigung, bitte nicht tot machen.
Das war vorher auch anders. Ich dachte, die Definitionen im Startupfile
mit den verzweigen dann sowieso auf die richtige Funktion. Aber das war
nicht das Problem!
MfG peter
Hey,
habe ich jetzt immer noch was falsch in der letzten startup-Datei
hochgeladen habe, oder war das einfach nicht der Fehler.
Ich denke nämlich, dass ich jetzt schon verstanden hab, was holger
meinte, aber es löst das Problem nicht. Es wird immer noch beim svc call
in den hard-fault handler gesprungenn. Interessanterweise wird wenn ich
vor dem svc call ein b vPortSVCHandler mache, in den SVC Handler
gesprungen. Natürlich passiert dann dort auch wieder ein HardFault.
MfG. peter
/Users/thinkJD/arm_toolchain/yagarto-4.6.2/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/v7m/libc.a(lib_a-abort.o): In function `abort':
3
/Users/mfischer/Projects/yagarto/newlib-build/arm-none-eabi/thumb/v7m/newlib/libc/stdlib/../../../../../../../newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
4
/Users/thinkJD/arm_toolchain/yagarto-4.6.2/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_kill_r':
5
/Users/mfischer/Projects/yagarto/newlib-build/arm-none-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
6
/Users/thinkJD/arm_toolchain/yagarto-4.6.2/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_getpid_r':
7
/Users/mfischer/Projects/yagarto/newlib-build/arm-none-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
8
/Users/thinkJD/arm_toolchain/yagarto-4.6.2/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/v7m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
9
/Users/mfischer/Projects/yagarto/newlib-build/arm-none-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'
10
collect2: ld returned 1 exit status
11
make: *** [freertos.elf] Error 1
Es scheint etwas mit meinem Makefile nicht zu stimmen.
Eventuell kann mir jemand auf die Sprünge helfen?
Grüße thinkJD
Wichtig ist der Eintrag: -ffunction-sections
Das bewirkt, dass der Compiler alle Funktionen in ein extra
.text-segment packt und die nicht benötigten werden mit --gc-sections
rausgeschmissen. Dein Code sollte dadurch auch kleiner werden.
Die Linkerfehler kommen aber aus der newlib. Sobald du irgendeine der
Funktionen wie printf sprintf puts u.s.w. benutzt, sind die Fehler
wieder da. Mann muss dann entweder diese Funktionen wie _sbreak _getpid
programmieren (meistens sind's nur Dummys) oder auf alle Funktionen
verzichten die diese Linkerfehler auslösen.
Am besten aus meiner Sicht ist es für die gesamte (xx)printf-Schiene
eine der häufig zu findenden Mini-Implementierungen zu verwenden. Das
spart eine Menge an Code der dazugelinkt wird.
Hey,
vielen Dank für die schnelle Antwort.
Ich habe die Änderung gemacht, habe aber immer noch die selben
Linkerfehler.
Was ich nicht verstehe, warum läuft das bei Dir und bei mir nicht.
War de eine Änderung in yargato? Ich hab an den Sourcefiles nichts
geändert.
Gruß JD
