Hallo liebe μC-Gemeinde!
Ich bin schon seit langem eifriger Leser und hab nun auch mal eine Frage
zu stellen:
Wo werden bei einem STM32L1-Projekt in Eclipse die
Interruptadressen/Interruptvektortabelle definiert?
Ich habe ein Projekt mit einem STM32L152 Eval. Board und einem dazu
passenden JTAG angefangen. Ich kann den Chip flashen und debuggen. Des
Weiteren ist es kein Problem die Peripherie des Chips in Betrieb zu
nehmen. So läuft beispielsweise das Timer-Modul und das LCD-Modul völlig
problemlos.
Was aber nicht geht :
Ich kann keine Interrupts ausführen. Initialisiere ich ein Interrupt
führt es schon nach sehr kurzer Zeit zu einem " Hard Fault " . Ich
vermute dass die Interrupts nicht mit dem Namen definiert sind wie sie
im Interrupthandler stehen.
Zu diesem Verdacht komme ich daher, weil ich ein Example-Projekt von
Eclipse verwende, in welches ich die Standard-Bibliotheken von ST
eigebunden habe.
Unverändert ist allerdings noch die Startupdatei und die Linkerscripts.
Ich bin heil froh, dass das Projekt läuft, wenn die Interrupts noch
funktionieren würden wäre endlich alles super... hilfe !
Board : Eval.Board von Olimex
(https://www.olimex.com/Products/ARM/ST/STM32-P152/)
JTAG : ARM-USB-TINY-H JTAG von Olimex
(https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY-H/)
Eclipse eingerichtet nach Anleitung :
https://balau82.wordpress.com/2014/02/23/stm32-p152-development-with-eclipse-on-linux/Anhang :
- Linkerscrips
- Startupdatei
Hallo Hans,
da hast Du dir wohl leider ein Board ausgesucht das nicht von dem
eclipse Assistenten unterstützt wird.
Wenn Du ein allgemeines cortex-m3 Projekt anlegst ist natürlich auch nur
das absolut notwendigste dabei.
Den L152 kennt eclipse (noch) nicht.
Hier:
http://www.emblocks.org/forum/viewtopic.php?f=26&t=611
in der zip hast Du ein Beispiel das alle nötigen Dateien enthält. Du
musst es natürlich für eclipse anpassen.
Viel Glück!
Interrupts.
HA!
Ein teilweise ähnliches Problem wie beim Threadstarter:
Hab hiern 407 auf dem ein Blink-a-Led Timer-Interrupt Example (für
Eclipse angepasst) einwandfrei läuft. Dann das gleiche per C&P mit ein
paar kleinen semantischen Anpassungen in ein Projekt einkopiert -
Flasche leer. Ich habe in den zehn Stunden Fehlersuche viel über den
Timer rausgefunden :-). Laut Debugger sind die zum Timer-Example
zugehörigen Register ebenfalls ok - aber die ISR wird einfach nicht
angesprungen. Als ob der NVIC - die Mitarbeit verweigert. Muß der NVIC
im Startup vor main() zuerst zum Leben erweckt werden, so ähnlich wie
die Peripherals, die erst betaktet werden müssen?
Gegen das Gedöns hier ist PIC18 und Atmega lauwarmer Kaffee...
timertick_t schrieb:> Muß der NVIC> im Startup vor main() zuerst zum Leben erweckt werden, so ähnlich wie> die Peripherals, die erst betaktet werden müssen?
Nö.
Schau dir die EXTI Beispiele an.
Die gibt es in der StdPeriphLib und auch in der HAL.
Hallo hp-freund,
vielen Dank für deine Antwort und das Sample. Das werde ich auf jeden
Fall ausprobieren. Ich würde aber gern nochmal zum Kern meiner Frage
kommen:
Wo werden die Interrupt-Adressen mit den C-Routine-Namen verknüpft bzw.
wo wird die Interrupt-Vektor-Tabelle festgelegt. Mir fehlt so ein
bisschen das Verständnis für Linkerscript und Startup.
die Zuordnung festgelegt.
Die Reihenfolge ab Zeile 70
1
__isr_vector:
2
.long__StackTop/* Top of Stack */
3
.longReset_Handler/* Reset Handler */
4
.
5
.
6
.
entspricht der tatsächlichen Hardware und darf nicht verändert werden.
Die Funktionen sind mit weak gekennzeichnet d.h. sind Platzhalter und
müssen überschrieben werden.
Im linker script
1
stm32l152vb_flash.ld
steht als erster Eintrag in der .text section:
1
KEEP(*(.isr_vector))
damit steht die Vectortabelle als erstes im Flash.
Die eigentliche Definition der IT-Funktionen findet sich in:
1
SPL/inc/stm32l1xx_it.h
2
SPL/inc/stm32l1xx_it.c
Also schau dir diese 4 Dateien und die main.c genauer an, damit dürfte
sich vieles klären...
Vielen Dank für eure Antworten!
Jetzt weiß ich wo es hängt und klemmt.
Ist es auch möglich in meine aktuelle Startup-Datei die
Interruptdefinition mit einzufügen? Oder gibt das Probleme, weil meine
Startup in C geschrieben ist und die aus dem Template in Assembler?
Ich hab festgestellt :
• Das EmBitz -Projekt ist unter Eclipse gar nicht so leicht
einzubinden, hat jemand einen Tip oder ein Tutorial für mich wie man
fremde Projekte in Eclipse sinnvoll einbindet? Mit dem Importieren-Menü
klappt es auf jeden Fall nicht. Es wird nicht mal aufgelistet.
• EmBitz selbst läuft zwar unter Ubuntu (ich habe kein Windows), aber
OpenOCD springt daraus heraus nicht an. Hat da jemand Erfahrungen?
EmBitz scheint ja insgesamt noch nicht so stark benutzt zu sein. Ich
finde leider keine Themen zur Einrichtung von OpenOCD mit ARM-USB-TINY-H
und STM32L.
Man kann zwar alle von mir verwendeten Komponenten auswählen, aber so
richtig loslaufen will der Debugger nicht.
@hp-freund: Hast du einen Lösungsvorschlag??
Console(Debugger-target):
Hast du mal die einzelnen Beiträge auf
http://gnuarmeclipse.livius.net/blog/ durchgemacht? Damit habe ich mein
STM32L151-Projekt mit OpenOCD und ST-Link zum Laufen bekommen.
Also nochmal herzlichen Dank für all eure Antworten. Mit dem Template
von hp-freund und ein bisschen Schweiß und Mühe hab ich ich es jetzt hin
bekommen.
Um das Template in Eclipse einzubinden müssen die folgenden
Einstellungen gemacht werden:
Unter "Project‣Proporties‣C/C++General‣Paths and Symbols‣Includes" in
alle 3 Sprachen (Assembly, GNU C, GNU C++) die folgenden Pfade einfügen:
/${ProjName}/inc
/${ProjName}/SPL/inc
/${ProjName}/cmsis
Unter "Project‣Proporties‣C/C++General‣Paths and Symbols‣Symbols" in
alle 3 Sprachen (Assembly, GNU C, GNU C++) die folgenden Symbole
einfügen:
DEBUG
OS_USE_TRACE_SEMIHOSTING_DEBUG
TRACE
USE_STDPERIPH_DRIVER
Unter "Project‣Proporties‣C/C++General‣Paths and Symbols‣Source
Location" die folgenden Pfade einfügen:
/${ProjName}/
/${ProjName}/SPL/scr
/${ProjName}/scr
Unter "Project‣Proporties‣C/C++Build‣Settings‣Tool
Settings‣Optimization" die folgenden Punkte abhacken:
Message length
'char' is signed
Function sections
Data sections
Assume freestanding environment
Disable loop invariant move
Unter "Project‣Proporties‣C/C++Build‣Settings‣Tool Settings‣Warnings"
die folgenden Punkte abhacken:
Enable all common warnings
Enable extra warnings
Unter "Project‣Proporties‣C/C++Build‣Settings‣Build Artifact" die
folgenden Einstellungen machen:
Artifact Type: Executable
Artifact name: ${ProjName}
Artifact extension: elf
Unter "Project‣Proporties‣C/C++Build‣Settings‣Tool Settings‣Cross ARM
GNU Create Flash Image‣Output file format" die folgenden Einstellung
auswählen:
Raw binary
Leider wird bei mir gerade das Binary nicht mit gebuildet. Daher muss
ich es von Hand in der Konsole machen:
Hans Achterbahn schrieb:> mit Schweiß und Mühe hab ich ich es jetzt hin bekommen.
So soll es sein. Ich hätte es auch für dich machen können, aber so ist
es natürlich viel besser :-)
Wenn die .bin nicht erstellt wird, führe doch ein "make" in von der
Konsole aus, vielleicht gibt es doch noch eine Warnung irgendwo...
Was mir in deiner Aufzählung fehlt ist die Controller Auswahl:
neben
Alles klar, dann füge ich die zwei Symbols noch hinzu.
Kurze Frage noch zu SYMBOLS:
- Was sind das eigentlich für Dinger ? -
Wo soll ich das "make" ausführen? im Debug-Ordner, da wo die Projekt.elf
liegt?
Die fehlende Symboldefinition des Controllers müsste er eigentlich in
der stm32l1xx.h bemängeln. Benutzt Du die überhaupt?
***
Die Symbole werden dem compiler als -D... Parameter übergeben.
***
make -> im Debug oder Release Ordner, da ist das makefile
Aber das Problem mit dem nicht erstellten .bin liegt wohl woanders.
Ich vermute wenn Du die Tool-Settings aufrufst ist der letzte Eintrag
der linker. Sollte aber wie im Bild aussehen.
Scheint ein bug im arm Plugin für ein leeres Projekt zu sein.
Hier:
http://mcuoneclipse.com/2014/01/19/diy-free-toolchain-for-kinetis-part-8-processor-expert-eclipse-and-gnu-arm-eclipse-plugins/
schreibt einer das es beim 2. Versuch funktioniert hat.
Hans Achterbahn schrieb:> DEBUG> OS_USE_TRACE_SEMIHOSTING_DEBUG> TRACE> USE_STDPERIPH_DRIVER
Die habe ich in C/C++Build, Settings, Tool Settings, Cross ARM C
Compiler, Preprocessor, Defined Symbols eingetragen und von dort landen
sie automatisch an der Stelle an der du sie eingetragen hast. In ASM
wirst du die in der Regel nicht brauchen, sondern nur in C.
Hans Achterbahn schrieb:> /${ProjName}/> /${ProjName}/SPL/scr> /${ProjName}/scr
Ich kann mich nicht erinnern da jemals was Hand eingetragen zu haben.
Hans Achterbahn schrieb:> Assume freestanding environment> Disable loop invariant move
Die beiden habe ich nicht abgehakt, dafür den LinkTimeOptimizer.
Geschmackssache.
Hans Achterbahn schrieb:> Raw binary
Da habe ich Intel HEX. Wohl ebenfalls Geschmackssache.
Hans Achterbahn schrieb:> Leider wird bei mir gerade das Binary nicht mit gebuildet. Daher muss> ich es von Hand in der Konsole machen:
Schmeiss das mal nach C/C++Build, Settings, Build Steps, Post-Build
Steps, Command: arm-none-eabi-objcopy -S -O binary "${ProjName}.elf"
"${ProjName}.bin"
Ich kann dir aber grad nicht mehr sagen wo ich das her habe - auf jeden
Fall aus irgendeinem Tutorial.
Hans Achterbahn schrieb:> Kurze Frage noch zu SYMBOLS:> - Was sind das eigentlich für Dinger ? -
Das ist quasi wie ein #define das nicht aus dem Code, sondern aus der
Toolchain kommt.
hp-freund schrieb:> Sollte aber wie im Bild aussehen.
Spielt egtl. keine Rolle. Sobald du C/C++Build, Settings, Toolchains,
Create extended listing deaktivierst und Apply klickst, dürfte der
Eintrag verschwunden sein und es wird kein Listing mehr produziert. Der
Rest aber schon.
Zwei Fragen hätt ich:
1) Sind die STM32F4 zu den STM32F0 hin eigentlich (mehr oder weniger)
abwärtskompatibel? Oder ist das mehr so wie AtMega <-> AtXmega?
2) Ist openocd + stlink ähnlich leistungsstark wie ein 'richtiger'
Debugger in der Preisspanne von 50...100 EUR?
Joachim .. schrieb:> Zwei Fragen hätt ich:> 1) Sind die STM32F4 zu den STM32F0 hin eigentlich (mehr oder weniger)> abwärtskompatibel? Oder ist das mehr so wie AtMega <-> AtXmega?
Der Binärcode an sich ja, aber die Peripherie + Register nein. Teilweise
werden bei unterschiedlichen STM32 völlig andere Peripheriemodule
verbaut, die ganz anders zu verwenden sind.
> 2) Ist openocd + stlink ähnlich leistungsstark wie ein 'richtiger'> Debugger in der Preisspanne von 50...100 EUR?
Nein, der J-Link z.B. (50€ für privat) ist viel schneller, stabiler, hat
keine Probleme mit Reset
Hans Achterbahn schrieb:> Wo werden bei einem STM32L1-Projekt in Eclipse die> Interruptadressen/Interruptvektortabelle definiert?
Du hackst die ganze Zeit auf die verkehrte Kerbe ein.
Also:
dein µC ist doch ein Cortex M3, ja?
Dann befinden sich die Interruptvektoren immer in einer Tabelle direkt
am Anfang des Flash - von einem evt. Remap sehen wir mal ab.
Diese Vektoren müssen natürlich auf die zugehörigen Handler zeigen und
zu diesem Zweck gibt es im Startupcode einen Sammel-Dummy, der aber als
[WEAK] gekennzeichnet ist.
In deinem Programm mußt du einen exakt gleichnamigen Handler schreiben,
der dann anstelle des weak-Dummies vom Linker eingebunden wird.
Das hat allenfalls mit der Toolchain zu tun, aber nicht mit einer IDE.
Die kann allenfalls die Toolaufrufe verhunzen.
W.S.
Hab zum Spass mal das Blinky-Projekt für das Olimex STM32-P152 in luna
und kepler erstellt. Ohne Garantie, da ich das Board nicht habe.
Darf gern getestet und verbessert werden...
Joachim .. schrieb:> Sind die STM32F4 zu den STM32F0 hin eigentlich (mehr oder weniger)> abwärtskompatibel?
Nein. Wobei es mit STM32Cube und diversen anderen Frameworks
Bestrebungen gibt, universell/portabel zu sein. Wie gut das in der
Praxis aber funktioniert, kann ich nicht sagen.
Micha schrieb:> Schmeiss das mal nach C/C++Build, Settings, Build Steps, Post-Build> Steps, Command: arm-none-eabi-objcopy -S -O binary "${ProjName}.elf"> "${ProjName}.bin"
Danke Micha, das hat geholfen!
hp-freund schrieb:> Hab zum Spass mal das Blinky-Projekt für das Olimex STM32-P152 in luna> und kepler erstellt. Ohne Garantie, da ich das Board nicht habe.> Darf gern getestet und verbessert werden...
Die Kepler-Version lässt sich problemlos einbinden. Leider wird sie
nicht gleich gebuildet und debugt. D:
Die Luna-Verion hab ich nicht probiert... :)
@hp-freund: Trotzdem vielen Dank für die Arbeit