STM32 - Eclipse - GCC - Sind Interruptadressen in Startup definiert?

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.

und natürlich die TIM Beispiele...

In dem Projekt von oben wird in der:

1

src/startup_stm32l1xx_md.S

die Zuordnung festgelegt.

Die Reihenfolge ab Zeile 70

1

__isr_vector:

2

    .long    __StackTop            /* Top of Stack */

3

    .long    Reset_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...

Sehr schön beschrieben ist das Ganze hier:

http://fun-tech.se/stm32/OlimexBlinky/mini.php

Zusammen mit den anderen Kapiteln sind alle Zusammenhänge leicht 
erkennbar.

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.

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

1

   USE_STDPERIPH_DRIVER

noch wie in der main.c angegeben

1

    STM32L152VB

2

    STM32L1XX_MD

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.

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.