Debbuging Modus funktioniert nicht wie er sollte (AMTEL Studio 7)

[Maximilian S. (maxi66)]

Hallo liebe Forenmitglieder,

als Mikrocontroller-Neuling wollte ich einfache Programme im ATMEL 
Studio 7 (Simulator) programmieren.

Jedoch scheint es als ob mir der Debugging-Modus einen Streich spielen 
möchte.

Ich verwende für den Simulator einen ATMEL 32.

Hier der Code:

#include <avr/io.h>

int main(void)
{
    DDRA = (1 << PA7);  // PORTA (Pin A7) auf Ausgang setzen
  
    while (1) 
    {    
       PORTA |= (1<<PA7);    //Bit setzen
       PORTA &= ~(1 << PA7); //Bit löschen
    }
}

Sofern die Syntax und die Semantik stimmen, müsste nun die 
while-Schleife fortlaufend laufen und ständig das Bit setzen und 
löschen.
Wenn ich auf Step-Over klicke um die einzelnen Schritte durchzugehen, 
setzt er erstens das Bit überhaupt nicht und bleibt sogar beim Befehl 
"PA7 Bit löschen" einfach stehen, also wiederholt die Schleife nicht 
mehr.

Bin ich blöde, dass ich keinen Fehler erkennen kann, oder dazu ein Bug 
bekannt?
Bitte um Hilfe

lG

[Jim M. (turboj)]

"Step Over" ist beim letzten Befehl der Schleife falsch.

Muss stattdessen ein "Step into" sein, denn "über" die Endlosschleife 
kommt der Code niemals hinaus.

[Maximilian S. (maxi66)]

Hab es auch mit "Step Into" probiert.
Er setzt mir zwar den Port PA7 auf Ausgang.
Jedoch bleibt der Debugger wieder beim "Löschen Befehl" stecken und 
wiederholt die Schleife auch beim mehrmaligen "Step Into" oder "Step 
Over" klicken nicht mehr.

Ps. Ich möchte ja auch nicht aus der Schleife raus, ich möchte nur dass 
die Schleife unendlich mal wiederholt wird und die Befehle auch 
ausgeführt werden, was beides bei mir leider nicht geschieht.

lG

[Stefan F. (Gast)]

Versuche mal, den Optimizer zu deaktivieren, mittels Compiler Option -O0

[Dieter F. (Gast)]

Maximilian S. schrieb:
> Sofern die Syntax und die Semantik stimmen, müsste nun die
> while-Schleife fortlaufend laufen und ständig das Bit setzen und
> löschen.

Stimmt - macht sie auch - selbst bei Optimierung -O3.

Blöde Frage, ich weiß - hast Du "Built Solution (F7)" ausgeführt?

[Maximilian S. (maxi66)]

Stefan U. schrieb:
> Versuche mal, den Optimizer zu deaktivieren, mittels Compiler Option -O0

Wow jetzt funktioniert alles einwandfrei :D
Kannst du mir erklären was das genau bewirkt? Merkt sich der Compiler 
bei der Ausführung, dass genau der gleiche Vorgang durchgeführt wird und 
deswegen aus Optimierungsgründen nicht mehr wiederholen möchte?

> Blöde Frage, ich weiß - hast Du "Built Solution (F7)" ausgeführt?

Sowie "Built Solution" als auch "Built 'Mein Projekt'".

lG

[Dieter F. (Gast)]

Maximilian S. schrieb:
> Stefan U. schrieb:
>> Versuche mal, den Optimizer zu deaktivieren, mittels Compiler Option -O0
>
> Wow jetzt funktioniert alles einwandfrei :D

Nö, das kann es nicht gewesen sein. Ich habe mit -O3 compiliert:

int main(void)
{
  DDRA = (1 << PA7);  // PORTA (Pin A7) auf Ausgang setzen
  6c:  80 e8         ldi  r24, 0x80  ; 128
  6e:  8a bb         out  0x1a, r24  ; 26
  
  while (1)
  {
    PORTA |= (1<<PA7);    //Bit setzen
  70:  df 9a         sbi  0x1b, 7  ; 27
    PORTA &= ~(1 << PA7); //Bit löschen
  72:  df 98         cbi  0x1b, 7  ; 27
  }
  74:  fd cf         rjmp  .-6        ; 0x70 <main+0x4>

00000076 <_exit>:
  76:  f8 94         cli

00000078 <__stop_program>:
  78:  ff cf         rjmp  .-2        ; 0x78 <__stop_program>

Um SBI und CBI kommt der Compiler nicht herum.

[Maximilian S. (maxi66)]

> Nö, das kann es nicht gewesen sein. Ich habe mit -O3 compiliert:

Bei wir war der Optimizer auf -01 eingestellt wo es nicht funktioniert 
hat.
Auf -03 wird auch nichts bei der I/O View ersichtlich.
Nur auf -00 geht er wirklich wiederholt die einzelnen Schritte durch und 
zeigt diese auch bei der I/0 View an.

[Dieter F. (Gast)]

Maximilian S. schrieb:
> Bei wir war der Optimizer auf -01 eingestellt wo es nicht funktioniert
> hat.
> Auf -03 wird auch nichts bei der I/O View ersichtlich.

Spannend. Poste doch bitte mal beie .LLS-Files (also mit -O0 und -O3).

Was meinst Du eigentlich mit

Maximilian S. schrieb:
> ATMEL 32

Ich bin von einem ATMega32 ausgegangen - ist das korrekt?

[majortom (Gast)]

hi,
... gcc optimization/simulation - das verhalten kenne ich.
ist eigentlich ganz logisch, weil wenn der gcc rum optimiert, wie soll 
dann der c source code noch dazu passen?!
da stimmt dann auch kein breakpoint mehr und es sieht so aus, als wenn 
nichts richtig funktioniert.

stimmt aber nicht!

daher, geh mal im simulator auf disassembly und dann step rum!
dann siehst du, dass alles so läuft wie erwartet.


major tom

[Dieter F. (Gast)]

majortom schrieb:
> daher, geh mal im simulator auf disassembly und dann step rum!
> dann siehst du, dass alles so läuft wie erwartet

Guggst Du Video :-) - brauchst dann nicht auf "disassembly - wo soll das 
im debugger sein und wie soll er da rumsteppen - erzähl mal bitte ?" zu 
gehen.

majortom schrieb:
> ist eigentlich ganz logisch, weil wenn der gcc rum optimiert, wie soll
> dann der c source code noch dazu passen?!

Mal ausprobiert - für das Beispiel? Ja, ich kenne die 
Optimierungs-Probleme auch, deshalb habe ich mal gespielt.

[Dieter F. (Gast)]

Dieter F. schrieb:
> .LLS-Files

.LSS natürlich :-\

[majortom (Gast)]

... disassembly windowm wo?

alt+8 oder debug/window/...


alles wird gut!

[Dieter F. (Gast)]

majortom schrieb:
> alt+8 oder debug/window/...

Vielen Dank - aber nichts neues -> Video. Grundsätzlich aber (wenn GCC 
mal SBI als "SET" und "CLEAR" - z.B. bei ATMega328 - behandelt) sicher 
wertvoll.