Macht AVR Studio Fehler beim JTAG-DEbugging?

[Günter R. (galileo14)]

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

[Dirk (Gast)]

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

[Günter R. (galileo14)]

@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

[Wolfram (Gast)]

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

[Günter R. (galileo14)]

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