Debugger gesucht

[Strahleman]

Ich bin gerade dabei, mich ein wenig mehr mit Assembler-Programmierung zu beschäftigen. Da ich im Studium ebenfalls mit Assembler programmieren muss, dachte ich, wäre das gleich der richtige Schritt...
Nun habe ich mir das myAVR Workpad Pro gekauft und komm damit soweit auch gut zurecht. Nur leider hat das Programm keinen Debugger. Und bevor ich hier jetzt wegen jedem kleinen Fehler das Forum zuspamme, wollte ich mir erstmal einen passenden Debugger suchen, mit dem ich vllt. auch so meine Fehler finden kann.

Leider habe ich bis jetzt nichts passendes oder kostenloses gefunden. Hat wer von euch einen Tipp, welcher Debugger gut ist?

[fhs]

Hallo,

unter Windows: AVR Studio (kostenlos bei Atmel erhältlich: http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=2725 )
unter Linux: avr_simulator (kostenlos bei Sourceforge erhältlich: http://sourceforge.net/projects/avr )

Das AVR Studio kenne ich und kann ich empfehlen -- trotz einiger Schwächen ist der Debugger recht brauchbar. Den "avr_simulator" kenne ich nicht.

Gruß

Fred

[Strahleman]

Danke für die schnelel Antwort ;)
Das AVR Studio hatte ich bereits zum Programmieren mal installiert, konnte damit aber keien Verbindung zum Board herstellen. Verbindung zum PC besteht über LPT und egal, was ich als "Connection" probiert habe, schlug der Verbindungsaufbau immer fehl.

[fhs]

Du kannst ja weiter Deine jetzige Programmier-Software zum Flashen nehmen. Das AVR Studio arbeitet nur mit einigen wenigen Programmern zusammen (die findest Du unter Help|AVR Tools User Guide).
Wenn Du nicht den Simulator zum Debuggen verwenden willst, sondern die eigentliche Hardware, müsstest Du z.B. einen AVR Dragon nehmen -- der kann JTAG und Debug Wire.

[Strahleman]

Ja, ein Debugger, der mit der Hardware kommuniziert fände ich schon feiner. So langsam komme ich aber auch mit dem Simulator zurecht ;)
Ich habe da gleich schon eine Frage. Beim Debuggen von meinem Testprogramm kommt der Fehler 'AVR Simulator: Stack Underflow at 0x0032', wenn das Programm durchgelaufen ist. Was hat das zu bedeuten?

€; Ahja, an Adresse 0x0032 steht bei mir ein "ret" aus einer Subroutine. Ersetze ich dieses durch ein "rcall mainloop", funktioniert der Code. Dennoch komisch...

[thewulf00]

Lass mal sehen.

-> Google.de eintippen: 10 Sekunden
-> Den Fehler eintippen: 8 Sekunden
-> Suchen klicken: 2 Sekunden
-> Den ersten Treffern nutzen: 5 Sekunden
Ergebnis: http://www.mikrocontroller.net/topic/60901#478753

-> Einfach im Forum fragen, da wird schon einer suchen: Unbezahlbar.

[Strahleman]

Du wirst es mir wahrscheinlich nicht glauben, aber das habe ich mir selbst auch bereits mal durchgelesen (ich gehöre nämlich nicht zu denen, die ihre Fragen stellen in der Hoffnung, dass andere für sie googlen). Doch leider ist es ja auch so, dass es auf dem Controller so ist, dass das Programm hängen bleibt, wenn ich an der besagten Stelle "ret" verwendet. Mit "rcall mainloop" läuft alles, wie es soll. Ist also nicht dieser AVRStudio Bug.

€: Da es wohl mit Code besser zu verstehen ist (auch wenn nicht ganz Thema vom Thread hier):

.include "m8def.inc"

begin: rjmp main ; 1 POWER ON RESET
reti ; 2 Int0-Interrupt
reti ; 3 Int1-Interrupt
reti ; 4 TC2 Compare Match
reti ; 5 TC2 Overflow
reti ; 6 TC1 Capture
reti ; 7 TC1 Compare Match A
reti ; 8 TC1 Compare Match B
reti ; 9 TC1 Overflow
reti ;10 TC0 Overflow
reti ;11 SPI, STC Serial Transfer Complete
reti ;12 UART Rx Complete
reti ;13 UART Data Register Empty
reti ;14 UART Tx Complete
reti ;15 ADC Conversion Complete
reti ;16 EEPROM Ready
reti ;17 Analog Comparator
reti ;18 TWI (I²C) Serial Interface
reti ;19 Store Program Memory Ready

;------------------------------------------------------------------------
; Initialisierungen
;------------------------------------------------------------------------
main:
;--- Stack Initialisierung ---
ldi r16,high(RAMEND)
out SPH,r16
ldi r16,low(RAMEND)
out SPL,r16
; Register
ldi r17,0x00
ldi r18,0x00
ldi r19,0x00
; Ports initialisieren
cbi DDRB,0 ; PORTB0 auf Eingang mit PullUp
sbi PORTB,0
sbi DDRB,1 ; PORTB1 auf Ausgang
sbi DDRB,2 ; PORTB2 auf Ausgang
sbi DDRB,3 ; PORTB3 auf Ausgang
sbi DDRB,4 ; PORTB4 auf Ausgang
sbi DDRB,5 ; PORTB5 auf Ausgang
sbi DDRB,6 ; PORTB6 auf Ausgang
sbi DDRB,7 ; PORTB7 auf Ausgang
sbi DDRC,0 ; PORTC0 auf Ausgang
sbi DDRC,1 ; PORTC1 auf Ausgang
sbi DDRC,2 ; PORTC2 auf Ausgang
sbi DDRC,3 ; PORTC3 auf Ausgang
sbi DDRC,4 ; PORTC4 auf Ausgang
sbi DDRC,5 ; PORTC5 auf Ausgang
sbi DDRC,6 ; PORTC6 auf Ausgang
;------------------------------------------------------------------------
; Hauptprogramm-Schleife
;------------------------------------------------------------------------
mainloop: wdr
in r17,PINB
cp r18,r17
breq led
rjmp mainloop ; Sprung zum Beginn der Hauptprogrammschleife

;Subroutinen
;------------------------------------------------------------------------
led:
rcall myWait_30ms
inc r19
out PORTC,r19
rcall mainloop ; <<< Diese Zeile ist gemeint

myWait_30ms:
push r16
ldi r16,1
myWait_30ms_3:
push r16
ldi r16,143
myWait_30ms_2:
push r16
ldi r16,255
myWait_30ms_1:
dec r16
brne myWait_30ms_1
pop r16
dec r16
brne myWait_30ms_2
pop r16
dec r16
brne myWait_30ms_3
pop r16
ret

[fhs]

Hi,

entweder schreibst Du

mainloop: wdr
in r17,PINB
cp r18,r17
brne mainloop
rcall led ; dann mit "ret" zurück
rjmp mainloop

;------------------------------------------------------------------------
led:
rcall myWait_30ms
inc r19
out PORTC,r19
ret ; mit "rcall" zu "led" gesprungen, also mit "ret" zurück

oder:


mainloop: wdr
in r17,PINB
cp r18,r17
breq led
rjmp mainloop ; Sprung zum Beginn der Hauptprogrammschleife

;Subroutinen
;------------------------------------------------------------------------
led:
rcall myWait_30ms
inc r19
out PORTC,r19
rjmp mainloop ; <<< Diese Zeile ist gemeint

oder:


mainloop: wdr
in r17,PINB
cpse r18,r17
rjmp mainloop ; Sprung zum Beginn der Hauptprogrammschleife

;Subroutinen
;------------------------------------------------------------------------
led:
rcall myWait_30ms
inc r19
out PORTC,r19
rjmp mainloop ; <<< Diese Zeile ist gemeint


So ist es wenigstens formell richtig. Die Programmlogik habe ich nicht überprüft. "Schön" ist der Code auch nicht -- aber das lernt man erst mit der Zeit.

"rcall" legt die Rücksprungadresse auf den Stack, die von "ret" benutzt wird, zu PC+1 zurückzukehren. Bei "breq" und "rjmp" ist das nicht der Fall, also kannst Du nach einer solchen Verzweigung nicht mit "ret" zurückspringen! Wenn Du es doch versuchst, wird ein Wert vom Stack geholt und als Rücksprungadresse interpretiert -- die zeigt natürlich ins Blaue... Zudem korrumpierst Du damit den Stack(pointer).

Gruß

Fred

[Besserwessi]

Diese Fehlermeldung ist einer der Fälle wo der Smulator Vorteile hat. Auf der echten Hardware würde der Controller irgendwo hinspringen, jenachdem was gerade auf dem Stack, ggf. mit überlauf, gefunden wird.

[Strahleman]

@fhs: Vielen Dank. Daran lag es. Habe nun ret ersetzt und jetzt läuft das Programm genau so wie ich will ;)
Zur Schönheit des Programmes: Ja, formatiert ist es im Editor ein wenig anders, nur das übernimmt er hier mit den Tabs nicht. Benutze Workpad PLUS von myAVR und bin damit eigentlich als Anfänger sehr zufrieden ;)

@Besserwessi: Ja, dafür brauchte ich auch einen Debugger. Da sieht man wenigstens, was passiert. Ein Microcontroller sagt mir leider nicht, wo er gerade hingesprungen ist ;)