Eclipse OpenOCD STM32 Nucleo F1 blinkt nicht

[T.Baumbach (Gast)]

Hallo,

ich bin (immernoch) Anfänger im Bereich ARM Programmierung.
Ich habe das STM Nucleo-Board STM32F103RB und habe ein einfaches 
Blink-Programm für meinen STM32F103RBT6 erstellt. Als IDE habe ich 
Eclipse verwendet und die GNU-ARM-Tools usw. installiert.
Compilieren hat funktioniert (siehe eclipse_main.png).

Dann habe ich mit OpenOCD 'per Hand' in der DOS-Box die *.elf-Datei auf 
das Nucleo-Board geflasht. (siehe openOCD_DOS.png).

Leider blinkt die LED nicht. :-(

Wie kann ich jetzt den Fehler eingrenzen?


Danke!

[hp-freund (Gast)]

Warum von der Konsole?

Probiere mal:

run

oder

continue

[T.Baumbach (Gast)]

Hallo hp-freund,

danke.

>Warum von der Konsole?

Ich habe es auch mal aus Eclipse probiert da blinkt auch nichts.
Dann wollte ich den OpenOCD-Debugger aus Eclipse heraus nutzen um dem 
Problem näher zu kommen, der sagt mir aber immer:

>Function "main" not defined

(siehe main_not_defined.png)

Und ich weiß leider nicht wie ich dieses 'main not defined'-Problem 
beheben soll :-(

[T.Baumbach (Gast)]

Hier noch das Output von OpenOCD in der Eclipse console:

Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Started by GNU ARM Eclipse
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.268993
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x20036410
Info : flash size = 128kbytes
undefined debug reason 7 - target needs reset
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510, semihosting
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000003a msp: 0x4c05b510, semihosting
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510, semihosting
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510, semihosting
===== arm v7m registers
(0) r0 (/32): 0x00000020
(1) r1 (/32): 0x00000000
(2) r2 (/32): 0x2000003C
(3) r3 (/32): 0x2000083C
(4) r4 (/32): 0x080005A0
(5) r5 (/32): 0x200005E4
(6) r6 (/32): 0x00000020
(7) r7 (/32): 0x00000014
(8) r8 (/32): 0xBF76FFDF
(9) r9 (/32): 0xFFBFFFFD
(10) r10 (/32): 0x304C7B35
(11) r11 (/32): 0x9C473FE7
(12) r12 (/32): 0xFFDFEFFF
(13) sp (/32): 0x4C05B510
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0xB9337822
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x4C05B510
(18) psp (/32): 0xB4221B6C
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)

Danke für jede Hilfe...

[hp-freund (Gast)]

T.Baumbach schrieb:
> undefined debug reason 7 - target needs reset

[T.Baumbach (Gast)]

Hi,

>

keine Ahnung warum die Meldung erschienen ist, habe es nochmal gemacht, 
und da kam diese Meldung nicht mehr.

Im Debug-Fenster erscheint immer:

>No source available for "0xf3af4804"


Hier nochmal der OpenOCD Output auf der Eclipse-Console:

Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Started by GNU ARM Eclipse
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.276467
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x20036410
Info : flash size = 128kbytes
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510, semihosting
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000003a msp: 0x4c05b510, semihosting
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510, semihosting
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510, semihosting
===== arm v7m registers
(0) r0 (/32): 0x00000020
(1) r1 (/32): 0x00000000
(2) r2 (/32): 0x2000003C
(3) r3 (/32): 0x2000083C
(4) r4 (/32): 0x080005A0
(5) r5 (/32): 0x200005E4
(6) r6 (/32): 0x00000020
(7) r7 (/32): 0x00000014
(8) r8 (/32): 0xBF7EFFDD
(9) r9 (/32): 0xFFBFBFFC
(10) r10 (/32): 0x304C7B31
(11) r11 (/32): 0x9C473FF7
(12) r12 (/32): 0xFF9FEFFE
(13) sp (/32): 0x4C05B510
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0xB9337822
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x4C05B510
(18) psp (/32): 0x30221B6C
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)

[T.Baumbach (Gast)]

...

außerdem sehe ich, wenn ich CubeMXtest Debug anklicke unten:

>Function "main" not defined.

(siehe Screenshot)

[hp-freund (Gast)]

Was hast Du für eigenartige PC Adressen?

Ausführung im RAM?

Alles etwas merkwürdig.

[T.Baumbach (Gast)]

Hallo hp-freund,

> Ausführung im RAM?

Wo siehst Du das denn bitte?

Und wo wird das eingestellt? In den Debugger-Settings?

[Programmierer (Gast)]

hp-freund schrieb:
> Ausführung im RAM?
Das ist keine RAM-Adresse... Da wird irgendein Unsinn im Flash stehen 
und der Prozessor irgendwo ins Nirvana springen. Um die Korrektheit des 
Programms zu prüfen würde ich mal aus der .elf Datei eine .hex Datei 
machen (arm-none-eabi-objcopy -O ihex test.elf test.hex) und diese mit 
dem ST-Link-Utility flashen. Wenn es dann blinkt ist der Code korrekt 
und irgendwas in Eclipse/OpenOCD falsch eingestellt, sonst umgekehrt...

[T.Baumbach (Gast)]

Eclipse erstellt mir die .hex-Datei.
Habe die mit ST-Link Utility geflasht, aber es blinkt nichts.

Deshalb habe ich ja gedacht probier mal zu debuggen, aber das geht ja 
leider auch nicht.

Wie komme ich da nun weiter?

[T.Baumbach (Gast)]

In Eclipse, muss ich denn zum Debuggen erstmal den Debug-Server starten?

Und danach die Debug-Configuration ausführen?

Oder wie läuft das korrekte Debuggen in Eclipse ab?

[Programmierer (Gast)]

T.Baumbach schrieb:
> Wie komme ich da nun weiter?

Versuche erstmal ein funktionsfähiges Beispiel aufzutreiben und bringe 
das mit einer der Rundum-Sorglos-IDE's ans Laufen, wie z.B. Keil µVision 
oder Atollic Studio. Dann kannst du versuchen das mit OpenOCD zu 
flashen, und wenn das geht mit Eclipse. Das OpenOCD+ST-Link Gedöns ist 
ja leider nicht wirklich "stabil".
Dein Program Counter sieht von Anfang an komisch aus. Sicher dass die 
BOOT-Pins richtig beschaltet sind?
Alternativ: Setze einen Breakpoint beim Reset_Handler und schau ob der 
erreicht wird und laufe da schrittweise weiter, und schau wo es 
abstürzt.

[Programmierer (Gast)]

T.Baumbach schrieb:
> In Eclipse, muss ich denn zum Debuggen erstmal den Debug-Server
> starten?
Dein Debug-Server ist ja OpenOCD, den startet es ja scheinbar von 
selbst.

[T.Baumbach (Gast)]

Das funktionsfähige beispile habe ich bereits am Laufen.
Ich habe mit CooCox das Blink-Programm lauffähig.


>Dein Program Counter sieht von Anfang an komisch aus. Sicher dass die BOOT-Pins 
richtig beschaltet sind?

Da habe ich nichts selbst gemacht. Die Einstellungen kommen von CubeMX 
nach Auswahl des Nucleo-Boards werden da alle Einstellungen generiert.
Es sind dieselben die ich für CooIDE verwende, und dort funktioniert ja 
alles.

>Setze einen Breakpoint beim Reset_Handler und schau ob der
erreicht wird und laufe da schrittweise weiter, und schau wo es
abstürzt.

Wie soll ich das bitte machen wenn der Eclipse Debugerr nihht geht?


Nun wollte ich das Ganze halt mit Eclipse machen, aber ich weiß halt 
nicht wo der Fehler liegt.
Da beim Flashen mit ST-Link die LED nicht blinkt muss der Fehler 
irgendwo im Programm liegen.
Aber ich weiß halt nicht wie ich das eingrenzen kann.

main.c ist genauso wie das bei CooCox.
(Sind ja nur die zwei Zeilen im main.c-->while(1).
Ich denke irgendwo in der Toolchain habe ich wohl inkorrekte 
Einstellungen und dann wird vielleicht etwas compliert was vom C-Code 
funktionieren müsste, aber halt nicht korrekt für das Board compiliert 
wird.

Ich weiß aber nicht wo ich suchen soll/muss?

[Programmierer (Gast)]

T.Baumbach schrieb:
> Das funktionsfähige beispile habe ich bereits am Laufen.
> Ich habe mit CooCox das Blink-Programm lauffähig.
Das ist schonmal gut. Was passiert wenn du die .elf Datei von Coocox 
mithilfe von OpenOCD flashst?

>>Dein Program Counter sieht von Anfang an komisch aus. Sicher dass die BOOT-Pins
> richtig beschaltet sind?
>
> Da habe ich nichts selbst gemacht. Die Einstellungen kommen von CubeMX
> nach Auswahl des Nucleo-Boards werden da alle Einstellungen generiert.
> Es sind dieselben die ich für CooIDE verwende, und dort funktioniert ja
> alles.
Okay...
>>Setze einen Breakpoint beim Reset_Handler und schau ob der
> erreicht wird und laufe da schrittweise weiter, und schau wo es
> abstürzt.
>
> Wie soll ich das bitte machen wenn der Eclipse Debugerr nihht geht?
Rechtsklick auf die Zeilennummer neben der 1. Zeile nach dem 
Reset_Handler (in der startup-Datei), "Toggle Breakpoint", dann den 
Debugger starten.
Wäre nicht das erste mal dass der Debugger das Programm zwar richtig 
startet (sieht so aus in dem Screenshot), es aber vor der main() im 
Reset_Handler schon abstürzt und der Debugger dann nichts sinnvolles 
mehr anzeigt.
> Nun wollte ich das Ganze halt mit Eclipse machen, aber ich weiß halt
> nicht wo der Fehler liegt.
> Da beim Flashen mit ST-Link die LED nicht blinkt muss der Fehler
> irgendwo im Programm liegen.
Oder beim kompilieren, oder beim Flashen...
> Aber ich weiß halt nicht wie ich das eingrenzen kann.
>
> main.c ist genauso wie das bei CooCox.
> (Sind ja nur die zwei Zeilen im main.c-->while(1).
Hah. Da sind noch einige mehr Zeilen versteckt in der 
Takt-Initialisierung und GPIO-Initialisierung, wo man schon einiges 
falsch machen kann...
> Ich denke irgendwo in der Toolchain habe ich wohl inkorrekte
> Einstellungen und dann wird vielleicht etwas compliert was vom C-Code
> funktionieren müsste, aber halt nicht korrekt für das Board compiliert
> wird.
>
> Ich weiß aber nicht wo ich suchen soll/muss?
Du könntest ja mal den Build-Log zeigen und vielleicht sogar deine .elf 
Datei posten.

[T.Baumbach (Gast)]

Hi,

bevor ich die .elf-Datei poste, püfe ich nochmal mein Projekt.
Ich bin nach folgendem Tutorial vorgegangen:

http://klaus4.blogspot.de/2014/05/stm32f4-discovery-mit-opensource.html

beim Punkt 'Alle unnötigen Header-Files im Verzeichnis' bin ich mir 
nicht sicher, welche datei ich includieren muss.

Ich habe ja das Nucleo STM32F103 Board mit dem Cortex-M3 STM32F103RBT6.

ich habe jetzt zwei Include-Dateien, wo ich nicht weiß welche ich 
includieren muss:

1. stm32f103x6.h
2. stm32f103xb.h

Wofper steht hier das x jeweils?
Welche muss ich nehmen?

[./. (Gast)]

DB: 7  Ordering information scheme

Pin count
T = 36 pins
C = 48 pins
R = 64 pins
V = 100 pins

[T.Baumbach (Gast)]

Hallo Gast,

ich habe 64 Pins, müsste also R sein. Aber das hilft mir nicht weiter ob 
ich

1. stm32f103x6.h

oder

2. stm32f103xb.h

nehmen muss.


Habe es dann einfach getestet, bei stm32f103x6.h gab es einen Fehler in 
main.c

>Symbol 'SysTick_IRQn' could not be resolved.

Bei der anderen Datei konnte ich ohne Fehler kompilieren.

.elf-Datei habe ich nun angehängt.

Wo sehe ich den Build-Log?

[./. (Gast)]

Wenn da schon DB (wie Datenblatt) nebst Kapitelnummer steht...

Logischerweise steht da auch was "6" und "B" ist.

So wird das nichts mit Dir.

Wissen kann man nicht durch Rumprobieren ersetzen.

[hp-freund (Gast)]

So krass wollte ich es nicht sagen, aber die Speicheraufteilung sollte 
schon bekannt sein.

Wenn Du eine .lst Datei erstellst kannst Du den Programmverlauf mit den 
Speicheradressen nachvollziehen.

Deshalb auch meine Frage nach der Ausführung im RAM.

[T.Baumbach (Gast)]

Hi,

habe das Datenblatt im Kapitel 7 gesehen, aber das half mir bei der 
Auswahl der include-Datei nicht weiter.

Mein ARM ist STM32F103RBT6

Da könnte stm32f103x6.h also passen, wenn man das x als 'RBT' 
interpretiert.

stm32f103xb.h könnte aber auch passen, wenn man x als R interpretiert 
und Package und 'Temperatur range' wegdenkt.
Woher soll ich denn bitte wissen, wonach die Include-Datei benannt wird?
Mit Package und Temperatuer range Informationen oder ohne.

Und fragen hat ja noch nie geschadet - oder?

[Programmierer (Gast)]

T.Baumbach schrieb:
> Habe es dann einfach getestet, bei stm32f103x6.h gab es einen Fehler in
> main.c

Wenn dein Controller STM32F103R*B*T6 heißt, kann es doch nur die 
stm32f103x*b*.h sein, und nicht die stm32f103x*6*.h ... das "x" steht 
für "egal".

T.Baumbach schrieb:
> .elf-Datei habe ich nun angehängt.
Die .elf Datei ist quasi leer, enthält weder ISR-Vektor noch 
Startup-Code noch main()-Funktion. Kein Wunder dass der Controller 
sofort abstürzt beim ausführen. Du hast vermutlich vergessen, die 
startup_XXX.S mit zu kompilieren. Sie muss .S und nicht .s heißen damit 
eclipse sie erkennt.
> Wo sehe ich den Build-Log?
Im Reiter "Console" in Eclipse.

[T.Baumbach (Gast)]

>aber die Speicheraufteilung sollte schon bekannt sein.

Soweit bin ich ja noch nicht.
Ich habe das Tutorial durchgeführt um mit Eclipse erst mal eine 
lauffähige Umgebung zu erstellen.
Mit dem Blink-Testprogramm wollte ich mich dann in die 
ARM-Programmierung einarbeiten.
Was nutzt mir bitte das theoretische Wissen, wenn ich es nicht in der 
Praxis testen kann?
Klar kann ich wieder CooCox nehmen, aber da wird halt soviel versteckt, 
was interessant ist.

Wie kann ich bitte die .lst-Datei erstellen?

Und woher bekomme ich das Build-Log um es hier zu posten?

Danke!

[Programmierer (Gast)]

T.Baumbach schrieb:
> Und woher bekomme ich das Build-Log um es hier zu posten?

In deinem allerersten Screenshot sieht man den Build log unten im 
Fenster. Da wo "Incremental Build of..." steht. Leider ist er nicht 
vollständig, weil du vorher schon mal kompiliert hattest. Klicke mit der 
rechten Maustaste auf das Projekt links und dann auf "Clean Project", 
und kompiliere erneut (Hammer-Symbol), und dann erscheint der komplette 
Build-Log in eben diesem Fenster.

[hp-freund (Gast)]

T.Baumbach schrieb:
> Wie kann ich bitte die .lst-Datei erstellen?

Aus oben genannten Gründen funktioniert das sowieso nicht.
Normal wird das in eclipse beim linker eingestellt,
von der Kommandozeile:

 arm-none-eabi-objcopy -S CubeMXTest.elf > CubeMXTest.lst

Dir fehlen aber die linker und startup Einstellungen.

[T.Baumbach (Gast)]

Hallo,

@Programmierer:

>Die .elf Datei ist quasi leer, enthält weder ISR-Vektor noch Startup-Code noch 
main()-Funktion. Kein Wunder dass der Controller sofort abstürzt beim usführen. Du 
hast vermutlich vergessen, die startup_XXX.S mit zu kompilieren. Sie muss .S und 
nicht .s heißen damit eclipse sie erkennt.

Das war das Problem, jetzt läuft alles und meine grüne LED blinkt.

Danke!

Das Programm läuft also, zumindest, wenn man das per ST-Link Utility 
überträgt.

Jetzt werde ich mich erstmal damit beschäftigen, den OpenOCD Debugger 
ans Laufen zu bekommen.

Ihr habt mir sehr geholfen, werde mich dann mal einlesen, habe hier dazu 
das Buch ARM CORTEX-M3 MIKROCONTROLLER 'EINSTIEG UND PRAXIS' liegen.
Ist zwar für Atmel Cortex-M3 aber vieles kann ich sicher übernehmen.

Danke nochmals an alle!

[hp-freund (Gast)]

Sorry, habe oben einen Fehler gemacht.
Es ist nicht objcopy zum .lst erstellen, sondern:

arm-none-eabi-objdump -S CubeMXTest.elf > CubeMXTest.lst

oder

arm-none-eabi-objdump -h -S CubeMXTest.elf > CubeMXTest.lst