Forum: Mikrocontroller und Digitale Elektronik Seltsames Verhalten mit Debugger im Atmel Studio


von Daniel K. (daniel_k80)


Lesenswert?

Hallo zusammen,

ich habe ein komisches Verhalten mit dem Debugger im Atmel Studio, was 
ich nicht so recht verstehe.
Ich verwende diesen Programmcode um eine fest definierte Adresse im 
Programmspeicher auszulesen:
1
ldi r30, low(0x0770)
2
ldi r31, high(0x0770)
3
4
lpm r16, Z
5
inc r16
6
rjmp start

Über srec_cat verändere ich das Hex-File, sodass an der Adresse ein Wert 
steht. Das File sieht dann so aus:
1
:020000040000FA
2
:0A000000E0E7F7E004910395FBCF61
3
:010770000682
4
:00000001FF

Wenn ich das File nun im Atmel Studio über das Menü "Device Programming" 
aufspiele und dann den Flash auslese, habe ich an der besagten Adresse 
diesen Wert
1
:10076000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF99
2
:1007700006FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF82
3
:10078000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF79

Wenn ich nun zusätzlich in den Properties des Projektes unter "Tool" bei 
"Programming settings" den Punkt "Skip programming" auswähle und das 
Programm dann per Debug (F5) starte funktioniert das Programm und in r16 
steht der Wert drin.

Wenn ich nun aber in den PRoperties unter "Tool" bei "Programming 
settings" den Punkt "Erase entire chip" auswähle und dann per Debug (F5) 
starte funktioniert das Programm nicht mehr. In r16 steht dann 0xFF und 
beim Auslesen des Flashspeichers ist diese Adresse nicht beschrieben.
1
:1007E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF19
2
:1007F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF09
3
:10080000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8

Und das obwohl in der Build-Ausgabe steht, dass srec_cat ausgeführt 
worden ist:
1
"C:\Users\Danie\OneDrive\Desktop\AssemblerApplication1\AssemblerApplication1\AssemblerApplication1.asmproj" (target "Build" depends on it):
2
  Task "Exec"
3
    "D:\Atmel\7.0"\shellutils\srec_cat "C:\Users\Danie\OneDrive\Desktop\AssemblerApplication1\AssemblerApplication1\Debug\AssemblerApplication1.hex" -intel -generate 0x0770 0x0771 -constan-l-e 7 1 -o "C:\Users\Danie\OneDrive\Desktop\AssemblerApplication1\AssemblerApplication1\Debug\AssemblerApplication1.hex" -intel
4
  Done executing task "Exec".
5
Done building target "PostBuildEvent" in project "AssemblerApplication1.asmproj".
6
Target "Build" in file "D:\Atmel\7.0\Vs\Avr.common.targets" from project "C:\Users\Danie\OneDrive\Desktop\AssemblerApplication1\AssemblerApplication1\AssemblerApplication1.asmproj" (entry point):
7
Done building target "Build" in project "AssemblerApplication1.asmproj".
8
Done building project "AssemblerApplication1.asmproj".
9
10
Build succeeded.
11
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

Ich habe bei der Ausgabe extra einen anderen Wert genommen, damit ich 
sicher bin, dass die Ausgabe von dem Buildprozess beim Starten des 
Debuggers stammt.
Im erzeugten Hex-File ist der Wert drin:
1
:020000040000FA
2
:0A000000E0E7F7E004910395FBCF61
3
:010770000781
4
:00000001FF

Kann sich jemand einen Reim auf dieses Verhalten machen? Warum habe ich 
den Wert nur im Flashsspeicher, wenn ich über das Programmiermenü gehe 
und nicht wenn ich das Programmieren über den Debugger mache?

von c-hater (Gast)


Lesenswert?

Daniel K. schrieb:

> Kann sich jemand einen Reim auf dieses Verhalten machen? Warum habe ich
> den Wert nur im Flashsspeicher, wenn ich über das Programmiermenü gehe
> und nicht wenn ich das Programmieren über den Debugger mache?

Das ist doch trivial: Offensichtlich löst das Programmieren über den 
Debugger kein Rebuild des Codes aus (warum sollte es das auch tun?!)...

Das ist normales Verhalten. Selbst in besseren IDE's wirst du nur unter 
bestimmten Bedingungen wenigstens gewarnt, dass der Host-Code nicht mehr 
dem Targetcode entspricht.

von Daniel K. (daniel_k80)


Lesenswert?

c-hater schrieb:
> Daniel K. schrieb:
>
>> Kann sich jemand einen Reim auf dieses Verhalten machen? Warum habe ich
>> den Wert nur im Flashsspeicher, wenn ich über das Programmiermenü gehe
>> und nicht wenn ich das Programmieren über den Debugger mache?
>
> Das ist doch trivial: Offensichtlich löst das Programmieren über den
> Debugger kein Rebuild des Codes aus (warum sollte es das auch tun?!)...
>
> Das ist normales Verhalten. Selbst in besseren IDE's wirst du nur unter
> bestimmten Bedingungen wenigstens gewarnt, dass der Host-Code nicht mehr
> dem Targetcode entspricht.

Es muss ja einen Rebuild auslösen, weil wenn ich den Code kompiliere und 
über das Programmiermenü aufspiele steht der Wert im Flash. Wenn ich 
direkt danach den Code über den Debugger aufspiele steht der Wert nicht 
mehr im Flash, obwohl er im generierten Hex-File steht.

Und ich habe es gerade noch einmal verifiziert. Sowohl beim "normalen" 
bauen über F7, sowie beim bauen über den Debugger mittels F5 steht der 
Wert im Hex-File. Aber beim Flashen über den Debugger steht der nicht im 
Flash-Speicher, weil die Speicherzelle nach dem Auslesen auf 0xFF steht.

von holger (Gast)


Lesenswert?

>mittels F5 steht der Wert im Hex-File. Aber beim Flashen über
>den Debugger steht der nicht im Flash-Speicher

Soweit ich weiss flasht der Debugger eine ELF Datei und keine
HEX Datei.

von Daniel K. (daniel_k80)


Lesenswert?

holger schrieb:
>>mittels F5 steht der Wert im Hex-File. Aber beim Flashen über
>>den Debugger steht der nicht im Flash-Speicher
>
> Soweit ich weiss flasht der Debugger eine ELF Datei und keine
> HEX Datei.

Müsste dann nich eine ELF-Datei im Debug-Ordner liegen? Oder wird die 
zur Laufzeit zusammengebaut?

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.