Hi, Um Debugmeldungen (einfachen Text) via SWD auszugeben, bin ich auf das Tool stlink-trace [1] gestoßen. Mein erstes Testprogramm lässt eine LED blinken und gibt mir einen Text aus, den ich auch in der Konsole sehe. Also passt ja alles. Das Problem ist nur dass mein Programm am MC offensichtlich nicht mehr läuft/startet wenn ich stlink-trace nicht starte. Also nach einem Reset blinkt keine LED, erst wenn ich stlink-trace anwerfe. Scheint so als ob der MC (STM32F103) in einem "Debug Modus" steht und auf Meldungen via SWD wartet. Im stlink-trace.c Source werden ab der Zeile 394 auch direkt einige ARM Register beschrieben, die laut "ARMv7-M Architecture Reference Manual" zum "System Control Space" gehören. Kann es sein dass das Tool nicht mehr sauber aufräumt und deshalb nichts mehr geht? Hat jemand eine Idee wie ich da wieder raus komme? (wenns überhaupt daran liegt) [1] https://github.com/xor-gate/stlink-trace [2] http://www.pjrc.com/teensy/beta/DDI0403D_arm_architecture_v7m_reference_manual.pdf Herzlichen Dank, Max
Hat niemand eine Idee?
Wenn du im Debug Modus bist, wird gewöhnlich an der Startadresse oder bei der Main ein Breakpoint gesetzt, der die Ausführung stoppt und durch ein Event die Debug Probe benachrichtigt. Die Debug Probe cleared daraufhin die Pipe und lädt den nächsten korrekten PC, damit das Programm weiter laufen kann. Tl;dr: Keine Debug Probe -> ewig im Breakpoint gefangen. Kann im Detail bei dir natürlich abweichen, aber das ist das grobe Prinzip dahinter. mfg
Felix F. schrieb: > Wenn du im Debug Modus bist, wird gewöhnlich an der Startadresse oder > bei der Main ein Breakpoint gesetzt, Ja, aber üblicherweise nicht im Flash sondern in der Debug Hardware, also ist der spätestens nach Power-On weg. ARM CMSIS enthält eine analoge Funktion:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
Im Gegensatz zu oben verlinktem Code wird da vorher geschaut ob ITM überhaupt AN ist. Ohne die ersten drei Zeilen (ab Trace enabled) würde er sich im
1 | |
aufhängen. Was Dein Code wohl tut.
Ich will aber meinen MCU natürlich auch ohne Debug Probe (st-link v2) benutzen. Ich kann mich auch via st-util und gdb auf den MC hängen und dort mit continue das Programm laufen lassen, das funktioniert auch. Mit "info break" bekomm ich vom gdb die Meldung - "No breakpoints or watchpoints." Gibts noch andere, spezielle Breakpoints die ich via gdb einsehen/setzen/löschen kann? Danke, Max
@turboj: Jop, das ... das Problem war dass ITM_SendChar hängt, wenn kein SWD device verbunden ist. Nehme ich die Ausgabe raus, läuft mein Programm wieder. Danke für den Tip! Werd auch gleich deine ITM_SendChar routine versuchen. Danke, Max
Jim M. schrieb: > Ja, aber üblicherweise nicht im Flash sondern in der Debug Hardware, > also ist der spätestens nach Power-On weg. Da aber der Standarduser nur billige Hardware mit minimalen Kapazitäten hat, stehen solche Informationen zu 99% im Flash (Hexfile wird vor dem flashen manipuliert mit entsprechenden Op codes) genauso wie es auch beim OP ist. Sein Code wartet auf die Anwesenheit einer Probe, welche nicht vorhanden ist. Ob es jetzt Breakpoints oder was anderes ist, bleibt dabei unerheblich... mfg
Felix F. schrieb: > Ob es jetzt Breakpoints oder was anderes ist, bleibt dabei > unerheblich... In dem Falle war es alles andere als unerheblich, denn den Source Code kann er korrigieren.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.