Forum: Mikrocontroller und Digitale Elektronik Crossworks STM32 und Debugging


von Michael B. (bubi)


Angehängte Dateien:

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

von Reiner L. (Gast)


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:
1
void LED_1s(void)
2
{
3
  FlagStatus Status;
4
  Status = SysTick_GetFlagStatus(SysTick_FLAG_COUNT);
5
  
6
  if ( Status == SET ) 
7
  { 
8
    if(flag)
9
      GPIO_WriteBit(GPIOC, GPIO_Pin_12, Bit_SET);
10
    else
11
      GPIO_WriteBit(GPIOC, GPIO_Pin_12, Bit_RESET);
12
    flag = ~flag;
13
  }
14
}
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

von Michael B. (bubi)


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

von Michael B. (bubi)


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 :/

von Michael B. (bubi)


Angehängte Dateien:

Lesenswert?

Hier nochmal aktuelle Projektdatein und ein YouTube Link der das Problem 
ganz gut Zeigt...
http://www.youtube.com/watch?v=-9CZ2qHLSuw
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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.