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!
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 :-(
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:
1
Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)
2
Licensed under GNU GPL v2
3
For bug reports, read
4
http://openocd.org/doc/doxygen/bugs.html
5
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
6
adapter speed: 1000 kHz
7
adapter_nsrst_delay: 100
8
none separate
9
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
10
Started by GNU ARM Eclipse
11
Info : Unable to match requested speed 1000 kHz, using 950 kHz
12
Info : Unable to match requested speed 1000 kHz, using 950 kHz
13
Info : clock speed 950 kHz
14
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
15
Info : using stlink api v2
16
Info : Target voltage: 3.276467
17
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
18
Info : accepting 'gdb' connection on tcp/3333
19
Info : device id = 0x20036410
20
Info : flash size = 128kbytes
21
target state: halted
22
target halted due to debug-request, current mode: Thread
23
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510
24
semihosting is enabled
25
target state: halted
26
target halted due to debug-request, current mode: Thread
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...
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?
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?
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.
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.
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?
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.
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?
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?
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.
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.
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?
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.
>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!
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.
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:
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!
eclipse_main.png
(250 KB)
openOCD_DOS.png
(26 KB)
