Kein Debug Output bei STM32F4 und Openocd

Natalia schrieb:
> Kann mir jemand erklären, wie das mit den printf-Ausgaben beim debuggen
> funktioniert?

Du haettest es leider kaum schlechter spezifizieren koennen.
Also es gibt drei wesentliche Ansaetze, um printf auf einem 
Mikrocontroller nutzen zu koennen.

1. Du setzt printf auf einen UART Kanal, der dann entweder direkt mit 
einem Levelshifter an den COM Port deines Computers angeschlossen wird 
oder ueber einen UART/USB Adapter mit dem PC verbunden wird.
2. Du schliesst den Mikrocontroller zusaetzlich als USB Geraet an dem 
Computer an und emulierst einen virtuellen COM Port. Dafuer benoetigst 
du aber zusaetzliche Software auf dem Mikrocontroller.
3. Du verwendest Semihosting, welches dann ueber deinen Debugger laeuft 
(in deinem Fall openOCD).

In jedem Fall musst du printf mit deinem gewuenschten Output zuweisen 
(das geschieht nicht von alleine!). Am Besten funktioniert normal die 
erste Variante. Die zweite Variante ist mit aufwand verbunden und die 
dritte Variante ist irgendwie nicht so schoen und ich wuerde generell 
davon abraten, wenn es nicht noetig ist.
Ich nehme jetzt aber mal an, dass du die dritte Variante oder gar keine 
Variante verwendest.

Falls du es nun also auf die dritte Variante anlegst, dann sollte dir 
der folgende Link helfen koennen:
https://plus.google.com/+AndreyYurovsky/posts/5rupuziHKGC

Natalia schrieb:
> Wenn ich dich richtig verstehe, kann ich doch später
> einfach printf auf den UART (Variante 1) umbiegen.
Ja, einfach den UART initialisieren und die eine Funktion zum Schreiben 
der Zeichen austauschen. Ich hab mir dafuer ein paar von denen hier 
gekauft:
http://www.ebay.de/itm/USB-2-0-an-RS232-TTL-UART-Module-Konverter-6PIN-Serial-/251125751211?pt=DE_Computing_USB_Kabel_Hubs_Adapter&hash=item3a7842ddab

Damit kannst du einfach und guenstig ein Mikrocontroller mit Putty, 
HTerm, CoolTerm oder was auch immer debuggen. Ein Vorteil dabei ist, 
dass du die COM Verbindung nur einmal aufbauen musst und wenn du den 
Mikrocontroller neu startest, dann ist das andere Programm immernoch 
verbunden.

Natalia schrieb:
> Genau, Semihosting, danach hatte ich gesucht. Es geht darum, beim
> Entwickeln ein serielles Monitoring zu haben.
Die Ausgaben ueber UART koenntest du theoretisch auch im Code lassen und 
spaeter am fertigen Produkt noch fuer Kontrollen nutzen.

Natalia schrieb:
> Ok, glaube verstanden zu haben, warum du Semihosting nicht so schön
> findest. Korrigier mich bitte: Eine mit Semihosting kompilierte/gelinkte
> Firmware kann praktisch nicht eigenständig ohne den Debugger laufen,
> weil sie bei IO-Operationen in eine Exception läuft, die nur vom
> Debugger aufgelöst werden kann?
Ja, nein ^^

Also es ist einer der Effekte, den ich nicht mag. Danach kommt dann aber 
auch noch die Frage, wie die Daten aus dem Chip an den PC kommen. Der 
Debugger muss dafuer massiv in die Programmausfuehrung eingreifen. Der 
Effekt sind dann ganz wilde Ausfuehrungszeiten, auf die du dich nicht 
mehr verlassen kannst. Planst du hingegen eine UART Ausgabe ein, so 
kannst du dich eher auf das Verhalten verlassen (sowohl mit, als auch 
ohne Debugger).