Forum: Compiler & IDEs Problem beim Debug im Simulator im Microchip Studio 7.0


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peter B. (pitsoft21)


Angehängte Dateien:

Lesenswert?

Hallo,
neuerdings bekomme ich ein Problem wenn ich im Microchip Studio ein 
Projekt debuggen will. Dann startet der Debugger (im Simulator) nicht 
bei "Start" in der main.asm wo auch ein Breakpoint ist, sondern in der 
ersten includierten *.inc Datei.
Auch Neustart des Studions, Neuanmeldung und Erstellen eines neuen 
Projektes brachten keine Besserung.

Hat sonst noch jemand so erlebt?
[avrasm]
.include "m8def.inc"
.include "lcd4puts.inc"
.include "lcd4put.inc"
.include "lcd4ini.inc"
.include "warte1ms.inc"
.include "lcd4com.inc"
.include "lcd4cur.inc"

.equ takt=16000000
.equ lcdpen=portb
.equ lcden=pb2
.equ lcdprs=portb
.equ lcdrs=pb3
.equ lcdpdat=portd
.equ lcdbus='1'

.def curpos=r23
.def acku=r16

.cseg
rjmp start

;.org $13


start:
ldi acku,low(ramend)
[\avrasm]

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Peter B. schrieb:

> Hat sonst noch jemand so erlebt?

Nein, habe ich nicht.

> .def acku=r16

Entweder accu oder akku. acku sieht so richtig Scheiße aus. 
Wahrscheinlich so Scheiße, dass sich sogar der Simulator mit Grausen 
abwendet.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Ob S. schrieb:
> Peter B. schrieb:
>
>> Hat sonst noch jemand so erlebt?
>
> Nein, habe ich nicht.
>
>> .def acku=r16
>
> Entweder accu oder akku. acku sieht so richtig Scheiße aus.
> Wahrscheinlich so Scheiße, dass sich sogar der Simulator mit Grausen
> abwendet.

Ach übrigens:

Wenn die Includes blöderweise Code/Daten erzeugen (was sie nicht 
sollten), dann kann es gut passieren, das der Entrypunkt mitten darin zu 
liegen kommt.

Es fehlt die Reservierung für die Vektortabelle (oder zumindest den 
Reset-Vektor). Das muß immer passieren, bevor irgendwelcher sonstiger 
Code erzeugt wird.

Sprich: wenn Includes Code/Daten erzeugen (was sie, wie gesagt, nicht 
sollten) dürfen sie erst nach "rjmp start" included werden.

von Peter B. (pitsoft21)


Lesenswert?

Gut "Acku" ist keine richte Rechtschreibung. Aber es wäre schön, wenn 
man mir statt mit spöttischen Kommentaren mit inhaltlichen Tipps weiter 
helfen würde.
Ich möchte mein Programm zum Laufen bekommen.  (ATMEGA8 zur Ansteuerung 
einer LCD Anzeige in Assembler.)

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Peter B. schrieb:

> Aber es wäre schön, wenn
> man mir statt mit spöttischen Kommentaren mit inhaltlichen Tipps weiter
> helfen würde.

Das habe ich getan.

von Gerhard H. (hauptmann)


Lesenswert?

Peter B. schrieb:
> Dann startet der Debugger (im Simulator)

Hast Du keinen Debugger an echter Hardware dran? Warum ist die main.asm 
im Fenster doppelt? Wie schaut Dein Projekt im Solution-Explorer aus, wo 
ist da der Entry-Point? Gibt es besondere Meldungen im Build-Prozess?

Ob S. schrieb:
> Sprich: wenn Includes Code/Daten erzeugen (was sie, wie gesagt, nicht
> sollten) dürfen sie erst nach "rjmp start" included werden.

Genau. Doch sollte da schon ein Build Probleme machen.
Also: Los gehts in der Code Section immer mit Reset-Vektor und 
Interrupttabelle. Ein .org xx sollte man sich dort sparen und die 
Vektoren vollständig hinschreiben. Selbst wenn sie vorerst nicht 
gebraucht werden. Das kann sich schon bei Updates, spätestens aber im 
nächstbesseren Projekt ändern. Ohne Interrupts verzichtet man ja auf 
einen großen Teil Controller-Funktionalität.

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Gerhard H. schrieb:

> Hast Du keinen Debugger an echter Hardware dran?

Das ist doch für das Problem des TO völlig Wurscht, ob Simulator oder 
Debugger. Auch der Debugger würde in dem Code landen, der von der 
lcd4puts.inc ab Adresse 0 erzeugt wird.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Gerhard H. schrieb:

> Genau. Doch sollte da schon ein Build Probleme machen.

Nein. Solange kein explizites ".ORG 0" vor dem "rjmp start" steht, wird 
es keine Fehlermeldng geben. Das ist gültiger Code und er wird halt nach 
dem includierten Code in den Flash geschrieben. Das Problem ist nur: der 
Reset-Vektor ist nicht dort, wo dann das "rjmp start" steht...

von Gerhard H. (hauptmann)


Lesenswert?

Ob S. schrieb:
> Das ist doch für das Problem des TO völlig Wurscht, ob Simulator oder
> Debugger.

Ja das mag sein, mich würde die Frage trotzdem interessieren.
Das Microchip Studio hat hier und da so seine kontextabhängigen 
Macken...

Ob S. schrieb:
> Das Problem ist nur: der Reset-Vektor ist nicht dort, wo dann das "rjmp
> start" steht...

Ja, das stimmt natürlich.
Vermutlich kam meinereiner nie zu solchen denkwürdigen Problemen weil 
der Reset-Vektor natürlich immer der erste Code ist und sein muß. Also 
Peter: Die .inc Code-Files erst irgendwann nach start inkludieren. 
Probleme könnten sich trotzdem ergeben wenn darin noch weitere Daten 
(.equ) deklariert werden. Das besser alles am Anfang, vor dem Code 
(inkludieren).

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Gerhard H. schrieb:

> Vermutlich kam meinereiner nie zu solchen denkwürdigen Problemen weil
> der Reset-Vektor natürlich immer der erste Code ist und sein muß.

Nein, das ist durchaus nicht immer der Fall. Man kann schließlich die 
Lage des Resetvektors über die Fuses verändern. Bei jedem ATmega, bei 
jedem neuzeitlichen AVR8 (incl. der Tinys) und sogar bei einem 
klassischen Tiny (der wohl nur aus Marketinggründen Tiny geworden ist, 
von der Architektur her aber eigentlich ein Mega ist).

> Also
> Peter: Die .inc Code-Files erst irgendwann nach start inkludieren.

Besser: Alles, was Code/Daten erzeugt, einfach *.asm nennen. Man kann 
nämlich auch *.asm includen.

Dann wird es deutlich einfacher, den Überblick zu behalten, um sie an 
der richtigen Stelle zu includen. Solange die Fuses auf "Standard" sind, 
also frühestens nach dem Resetvektor.

Und damit man Fehler beim Speicher-Layout tatsächlich mitbekommt, ist es 
immer eine sehr gute Idee, Code, der an einer bestimmten Stelle liegen 
muss, mit dem entsprechenden ".ORG" auch an diese Stelle zu zwingen. 
Dann gibt's halt wenigstens eine Fehlermeldung beim Assemblieren, wenn 
anderer Code oder Daten überlappen.

von Gerhard H. (hauptmann)


Lesenswert?

Ob S. schrieb:
> Nein, das ist durchaus nicht immer der Fall. Man kann schließlich die
> Lage des Resetvektors über die Fuses verändern

Stimmt. Kann man. I.d.R. bleibts aber bei der Voreinstellung.

Ob S. schrieb:
> Und damit man Fehler beim Speicher-Layout tatsächlich mitbekommt, ist es
> immer eine sehr gute Idee, Code, der an einer bestimmten Stelle liegen
> muss, mit dem entsprechenden ".ORG" auch an diese Stelle zu zwingen.

Warum sollte Code an bestimmter Stelle liegen müssen (von der 
Interrupttabelle abgesehen)? Solche Extravaganzen sollte man tunlichst 
vermeiden, das verkompliziert unnötig.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Ob S. schrieb:

> bei
> jedem neuzeitlichen AVR8 (incl. der Tinys)

Das war Quatsch. Bei denen liegt der Resetvektor immer auf 0.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Gerhard H. schrieb:

> Warum sollte Code an bestimmter Stelle liegen müssen (von der
> Interrupttabelle abgesehen)?

Es gibt keine "Interrupttabelle". Es gibt eine Vektortabelle. Und die 
enthält halt u.a. auch den Reset-Vektor. Und genau der ist halt hier das 
Problem.

von Gerhard H. (hauptmann)


Lesenswert?

Ob S. schrieb:
> Und genau der ist halt hier das Problem.

Soweit sind wir uns einig.
Ansonsten: .org hat in der Code(Flash)-Section für Code nichts verloren. 
Man kann damit höchstens mal ein paar Daten im Flash positionieren aber 
meist ist selbst das entbehrlich.

> Es gibt keine "Interrupttabelle". Es gibt eine Vektortabelle

Jetzt werde mal nicht zu kleinlich.
Einigen wir uns auf Interruptvektortabelle!

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Gerhard H. schrieb:

> Ansonsten: .org hat in der Code(Flash)-Section für Code nichts verloren.

Unsinn. Hätte er ein ".ORG 0" vor "rjmp start" hingeschrieben (und damit 
die korrekte Lokalisierung für den Code des Resetvektors erzwungen), 
dann hätte er zumindest eine Fehlermeldung erhalten.

Das ist der Sinn von Fehlermeldungen: auf Programmierfehler (hier die 
falsche Reihenfolge der Code-Erzeugung) hinzuweisen. Leider steht aber 
natürlich in der Fehlermldung nicht "du Honk hast den Code in der 
falschen Reihenfolge erzeugt". Das herauszufinden, bleibt dem 
Programmierer überlassen. Aber so ein Hinweis kann trotzdem hilfreich 
sein. Wenn man halt programmieren kann, also wirklich versteht, was man 
da tut...

von Gerhard H. (hauptmann)


Lesenswert?

Ob S. schrieb:
> Unsinn. Hätte er ein ".ORG 0" vor "rjmp start" hingeschrieben (und damit
> die korrekte Lokalisierung für den Code des Resetvektors erzwungen),
> dann hätte er zumindest eine Fehlermeldung erhalten.

Sicherlich.
Wer so "dumm" ist Code vor den Reset-Vektor zu setzen hätte wenigstens 
das .org 0 gebrauchen können. Entschuldige Peter, jeder hat mal klein 
angefangen.

> Das ist der Sinn von Fehlermeldungen

Das Microchip-Studio kann damit durchaus recht verwirrend und unlogisch 
werden wenn gewisse stillschweigende Voraussetzungen nicht erfüllt 
werden. Mir fällt zwar gerade keiner dieser Fälle spontan ein (wieder 
länger her) aber da gibts über die Jahre durchaus einiges zu erleben.

> Wenn man halt programmieren kann, also wirklich versteht, was man da
> tut...

Das lernt man genau so , durch die dümmsten Fehler, am besten :)

Peter! Dranbleiben!

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Gerhard H. schrieb:

> Das Microchip-Studio kann damit durchaus recht verwirrend und unlogisch
> werden wenn gewisse stillschweigende Voraussetzungen nicht erfüllt
> werden.

Ähem, nein. Das hat mit dem Studio garnix zu schaffen. Das ist einfach 
der avrasm2. Der einzige Bestandteil der ASM-Toolchain. Und das Ding ist 
doch ziemlich gut dokumentiert (außer einigen Teilen des 
Asm-Präprozessors und dessen Wechselwirkungen mit dem ebenfalls 
eingebauten C-Style Präprozessor).

Das allerdings sind Feinheiten, die der TO voraussichtlich niemals 
brauchen oder bemerken wird...

Der einzige wirkliche Beitrag der IDE bei Asm-Projekten ist, das 
passende Target-Device-Include automatisch an den avrasm2 zu 
übermitteln. D.h.: das ".include m8def.inc" im Quelltext kann man sich 
in der IDE-Umgebung sparen. Es stört aber auch nicht, wenn es stehen 
bleibt. Zumindest nicht, solangem man wirklich beim Mega8 bleibt...

von Gerhard H. (hauptmann)


Lesenswert?

Ob S. schrieb:
> Das hat mit dem Studio garnix zu schaffen. Das ist einfach der avrasm2

Genaugenommen schon.
Für mich sind die halt mit Studiomeldungen identisch weil drin nur der 
Assembler lebt.

> solangem man wirklich beim Mega8 bleibt...

Hier kann ich Peter wiederum nur raten baldmöglichst auf einen aktuellen 
AVR umzusteigen. Gerade wenn man erst beginnt, in Asm zu programmieren 
(und dabei bleiben möchte).

: Bearbeitet durch User
von Peter B. (pitsoft21)


Lesenswert?

Erst mal Danke für die Beiträge. Ich habe es jetzt hinbekommen.
Folgende Änderungen waren nötig:
- Korrektur von "Acku" nach "Akku"
- Platzhalter für Interrupt Vektoren freihalten : .ORG $13
- Aufruf der Include Dateien nach .ORG $13
  sonst gab es den Fehler :Overlap in .cseg: addr=0x13 conflicts with 
0x0:0x63

Der Code sieht dann so aus:

[avrasm]
.include "m8def.inc"

.equ takt=16000000
.equ lcdpen=portb
.equ lcden=pb2
.equ lcdprs=portb
.equ lcdrs=pb3
.equ lcdpdat=portd
.equ lcdbus='1'

.def curpos=r23
.def akku=r16

.CSEG
rjmp start

.ORG $13


.include "lcd4puts.inc"
.include "lcd4put.inc"
.include "lcd4ini.inc"
.include "warte1ms.inc"
.include "lcd4com.inc"
.include "lcd4cur.inc"


start:
ldi akku,low(ramend)
out spl,akku
ldi akku,high(ramend)
out sph,akku
...


[\avrasm]

der Debugger startet wieder bei "Start". Jetzt kann ich die inhaltlichen 
Fehler suchen. Danke an alle.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Peter B. schrieb:

> Der Code sieht dann so aus:
[...]
> .ORG $13
[...]

Das schreibt man dann sinnvoller so:

.ORG INT_VECTORS_SIZE

Dann passt es automatisch auch dann, wenn du statt Mega8 z.B. einen 
Mega644 als Target wählst.

Das Symbol wird nämlich in den device-spezifischen Includes deklariert. 
Genau dazu, es z.B. für diesen Zweck zu verwenden.

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.