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

Maximilian S. (maxi66) OP 07.11.2017 23:14 #5201609

Lesenswert?

•

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

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Jim M. (turboj) 08.11.2017 00:24 #5201640

Lesenswert?

•

▲
▼

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

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Maximilian S. (maxi66) OP 08.11.2017 08:57 #5201800

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan F. Gast 08.11.2017 10:04 #5201877

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dieter F. Gast 08.11.2017 10:36 #5201916

Lesenswert?

•

▲
▼

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?

Angehängte Dateien:

08.11.2017_10-15-19.avi (4,09 MB)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Maximilian S. (maxi66) OP 08.11.2017 11:52 #5202044

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dieter F. Gast 08.11.2017 12:40 #5202125

Lesenswert?

•

▲
▼

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>:
00000078 <__stop_program>:
  78:  ff cf         rjmp  .-2        ; 0x78 <__stop_program>


Um SBI und CBI kommt der Compiler nicht herum.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Maximilian S. (maxi66) OP 08.11.2017 18:14 #5202665

Lesenswert?

•

▲
▼

> 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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dieter F. Gast 08.11.2017 18:24 #5202674

Lesenswert?

•

▲
▼

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?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

majortom Gast 08.11.2017 18:35 #5202682

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dieter F. Gast 08.11.2017 18:48 #5202694

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dieter F. Gast 08.11.2017 18:56 #5202703

Lesenswert?

•

▲
▼

Dieter F. schrieb:
> .LLS-Files

.LSS natürlich :-\

Antwort Zitieren Bearbeiten Löschen Beitrag melden

majortom Gast 08.11.2017 19:05 #5202713

Lesenswert?

•

▲
▼

... disassembly windowm wo?

alt+8 oder debug/window/...


alles wird gut!

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dieter F. Gast 08.11.2017 19:25 #5202750

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

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

Antwort schreiben