mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Crossworks STM32 und Debugging


Autor: Michael B. (bubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Da ich mir jetzt am Wochende von hier schneller Hilfe erhoffe poste ich 
einfach mal hier.

Ich verwende Crossworks(noch als Eval) und das STM32-H103 von Olimex zum 
rumspielen.
Bin erst heute soweit gekommen das ich alles angesteckt und mal veruscht 
habe. Erste kurze Tests haben auch funktioniert. Blinkende LED über 
Flags usw.
Ich hatte anfangs kurz das Problem dass das Debugging abgebrochen hat, 
habe mir aber nichts dabei gedacht da ichs auch schlechten Code 
zurückgeführt hab.
Jetzt bin ich aber eigentlich soweit das ich sage das kann irgendwie 
doch nicht sein...
Zum Problem:

Mein Programm tut nichts weiter als alles zu initalisieren und das LED 
auf dem Board zu togglen (ob das so mit dem Flag setzen geht weiß ich 
noch ned)
So scheint alles zu funktionieren bis ich das Debugging starte. Ich 
drücke einmal F5 und schaltet Crossworks direkt von der 
Debuggingoberfläche zurück in den C-Teil. Nur mit einer Meldung "Target 
Connection has been lost". Habe es auch schon mit dem DEBUG define 
probiert, aber nichts gefunden :(. Als Interrupt läuft nur der SysTick. 
Wenn ich im Crossworks den Simulator ausführe lande ich im HardFault... 
Ist Ansich schonmal kein gutes Zeichen.
Das komische ist aber das ich teilweise durchsteppen kann...wenn ich 
genug Breakpoints setze. Aber auch nur ab und an, sobald ich auf freerun 
gehe ist es sowieso vorbei :(

Achso als Debugger verwende ich den ARM-USB-TINY von Olimex...

€dit:

Mit "scheint alles zu funktionieren" meine ich Linken, compilieren usw.
Das Programm scheint auch auf dem Controller nicht zu laufen.

Ich hoffe mir kann wer helfen.
MfG
Michael

Autor: Reiner L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
da ich die fast identische Umgebung habe, bis auf den "tiny", da ist es 
die "OCD" Variante, hab ich die Files mal geladen. Du hast recht, 
compilieren tut CW ohne Fehler, nur laufen tuts so bei mir nicht, wegen 
assert_param Fehler. Habe es dann mal so umgeschrieben:
void LED_1s(void)
{
  FlagStatus Status;
  Status = SysTick_GetFlagStatus(SysTick_FLAG_COUNT);
  
  if ( Status == SET ) 
  { 
    if(flag)
      GPIO_WriteBit(GPIOC, GPIO_Pin_12, Bit_SET);
    else
      GPIO_WriteBit(GPIOC, GPIO_Pin_12, Bit_RESET);
    flag = ~flag;
  }
}
nun blinkt es auch, wenn auch schneller.
Das scheint aber nicht dein vorangiges Problem zu sein, es sieht ja so 
aus als wenn CW die Verbindung zum Debugger verliert.
Da kann ich dir nicht wirklich helfen nur meine bisherige Erfahrung 
mitteilen:
Auf meinem XP Notebook läuft alles superstabil und rund, mit meinem W2K 
Rechner bricht auch öfters die Verbindung ab oder es kommt bei 5 
Verbindungsversuchen 4 mal zu verify Fehlern, beim 5. mal gehts dann.
Manchmal scheint es zu funktionieren aber die CPU kann nicht gestoppt 
werden, usw...
Ich mache meine ersten Gehversuche erst seit 2 Wochen, deshalb hab ich 
noch kein wirklich großes Wissen.

LG
Reiner

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für den Hinweiß und die Antwort.
Wie hast du den assert_param rausgefunden? Bei mir bricht immer alles 
ab, ich komm garnicht zu meiner Debugg-Ausgabe, was wiederum heißt für 
mich ist der Debugger nutzlos...
Verify Fehler hab ich noch keine gehabt :/
Werde es morgen mal testen wenn ich wieder vor dem Teil sitze :)
Notfalls muss es zurück

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So gerade ausgetestet mit angepassten Code:
Es ändert sich nichts am Debugging Verhalten. Lost Target Connection 
weiterhin. Deaktiviere ich den DEBUG Mode von der FWLib, kann ich 
zumindest im THUMB FLASH RELEASE Mode in der DisamblyView Debuggen ohne 
Verbindungsabruch. Sobald ich aber wieder umschalte in den THUMB FLASH 
Debug Mode, damit die Default Einstellung fix C-Source ist bricht mir 
wieder die Verbindung zusammen :(

Irgendwie ist das Teil somit nutzlos für mich :(
Irgendwie scheint es als liege es am ARM-USB-TINY :(

€dit noch eine Erkenntnis, im AUTOSTEP Modus gehts auch :/ Jetzt bin ich 
mit dem JTAG Clock Divider schon auf 20 Testweise gegangen also wirklich 
extrem langsam, aber es ändert sich nichts :(
€dit sobald ich in die while(1) komme und den Debugger laufen lasse ohne 
Breakpoints isses Ende im Gelände :( Na toll :/

Autor: Michael B. (bubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal aktuelle Projektdatein und ein YouTube Link der das Problem 
ganz gut Zeigt...
Youtube-Video "STM32 Debugging Problems"
Zuerst FLASH-Release im Disambly View was ja geht
Dann Debugging im FLASH-Debug wo es direkt rauspringt. Dann Breakpoint 
und Autostep...und zum Abschluss nochmal Freerun mit Abbruch.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.