Ich muß jetzt doch mal 'nen Thread lostreten bezgl. eines Problems, das ich seit Anbeginn meiner Arbeit mit AVR Studio (4.2 SP2 Build 472) im Zusammenspiel mit WinAVR (WinAVR-20060421, mit AVR-LIB 1.4.4) fast täglich erlebe; bis jetzt traute ich mich nicht, damit ans Forum zu gehen, da man ja sehr vorsichtig sein muß mit der Unterstellung, das System habe einen Fehler (immer erst an der eigenen Haustüre scharren!). Ich teste mit einem Atmel STK500, dem Prozessor ATMega128 (auf STK501) und dem Olimex-JTAG-Interface (RS232-Version) C-Programme; es wird compiliert, dann das Flash programmiert ("Start debugging"), dann z.B. schrittweise gesteppt. Daß das System hin und wieder hängenbleibt bzw. abstürzt, ist man andernorts ja auch gewohnt, das regt einen nicht auf. Aber bei der genannten Systemumgebung kommt es gelegentlich - aber wie üblich nicht reproduzierbar - vor, daß das Stepping Wege nimmt, die normalerweise nicht möglich sind. Code-Beispiel: if (!flag) { ... code ... } ... weiterer Code ... Hier enthält "flag" den Wert 0x01, das bekommt man angezeigt, wenn man mit der Maus auf diese Variable zeigt (Tooltip-Anzeige); somit müßte bei der Ausführung der Block "{ ... code ... }" übersprungen werden; ich erlebte es aber eben gerade, daß die Ausführung in den Block hineinspringt und die dort gelegenen Anweisungen ausführt (was für die weitere Programmfunktion u.U. katastrophale Folgen hat ...). Bei nochmaliger Ausführung des gleichen Codes - nach Reset - funktioniert es an der genannten Stelle korrekt (geschweifte Klammer wird korrekt umsprungen), dafür kann ähnliches an anderer Stelle passieren. Desgleichen kommt es vor, daß Variableninhalte falsch angezeigt werden, wenn man mit der Maus daraufzeigt; z.B. habe ich vorhin erlebt, daß eine Zuweisung var2=var1; nach der Ausführung unterschiedliche Werte für var2 und var1 anzeigt (beide natürlich gleicher Datentyp, in meinem Fall "uint32_t"). Läuft das Programm in Realtime ab, also ohne Breakpoints oder Stepping, so funktioniert es einwandfrei; es liegt also nicht an fehlerhaftem Code. Daher die Frage ins Forum: Kennt jemand solche Probleme? Könnte es mit dem Olimex-JTAG-Interface zu tun haben, indem dort z.B. durch Übersprechen oder Impulsprobleme falsche Bits in die JTAG-Kette rutschen? Danke für eure Hinweise. Günter
Hi, > Daher die Frage ins Forum: Kennt jemand solche Probleme? Könnte es > mit dem Olimex-JTAG-Interface zu tun haben, indem dort z.B. durch > Übersprechen oder Impulsprobleme falsche Bits in die JTAG-Kette > rutschen? Wielang ist die Leitung zum Ziel? Bei >10cm hab ich bemerkt das man die Baudrate verringern sollte. Probier es doch am besten mal aus. Gruß, Dirk
@Dirk, danke für Deinen Hinweis. Vom JTAG-Adapter bis zum 10-pol-Stecker am STK501 sind es ca. 17 cm. Das Kabel vom PC zum JTAG-Adapter ist ca. 150 cm lang. Ich arbeite bei 19200 bps (default). Hast Du die beschriebenen Phänomene selbst auch erlebt? Auf welche (reduzierte) Baudrate, meinst Du, sollte ich erniedrigen? Günter
Ich benutze selbst JTAG und habe in letzter Zeit viel mit der Avrstudioversion gedebugged, Abstürze habe ich da noch nicht erlebt. Zu den von dir beschriebenen Problemen. Wenn du die C Ebene verlassen würdest und die darunterliegende Codeebene dir anschauen würdest(View Disassembly) dann würdest du merken das dies keine Probleme sind sondern einfach nur die Optimierung. Wenn du dein Programm auf der C Ebene überprüfen willst dann schalte die Optimierung aus. (O0) sonst passieren die von dir genannte "Probleme" 1.Variablen die "falsche" Werte zeigen oder sich nicht anzeigen lassen Ursache: Code der sinnlos ist( z.B. Bedingung tritt nie ein) und deswegen vom Optimierer entfernt wurde oder Variable in Register eine solche Variable kannst du dir anzeigen lassen, Sie ist aber in einem Register das davor oder danach (wenn die Variable nicht gebraucht wird) von anderen Sachen verwendet wird. Im Watch wird jeweils der Register wert angezeigt. (Auch wenn vom Code gerade nicht die Variable drin steht. 2. Sprung in Programmteile die eigentlich nicht im Kontrollfluss sind. Ursache: Optimierer Wiederverwendung von Codeteilen um Platz zu sparen
Hallo, Wolfram, danke für Deine Hinweise; ja, das kann ich nachvollziehen, daran könnte es liegen. D.h. man schaltet die Optimierung zum Debuggen aus, wenn alles okay ist, später wieder ein für die "Produktionsversion". Prima. Probiere ich so. Danke. Günter
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.