Problem mit Interrupt

[The Man]

Hallo da,
ich versuche mich gerade am Interrupt mittels Comparematch im CTC Mode.
Das läuft aber nicht so ganz. Ich weiß vorallem nicht, was mir diese Fehlermeldung sagen will.
Vielleicht kann mir jemand sagen, was ich falsch mache.
Danke

[wkrug]

Ich seh da auf Anhieb keine Fehlerquelle.

Hast Du das Programm schon mal im Simulator getestet ?
Was passiert wenn der Counter 2 den Zählerstand 255 erreicht ?
Was passiert wenn du das Comparematch Interrupt Flag des Timers 2 manuell im Simulator auf 1 setzt ?

[The Man]

Hallo nochmal,
hab noch etwas rumexperimentiert und die fehlermeldungen sind weg.
Vorallem die meldung mit dem "odd" ist weg.
Nur tun, tut sich nix.
Kann da jemand helfen?

.include	"AVR.H"
;------------------------------------------------------------------------
;Reset and Interrupt vector             ;VNr.  Beschreibung

;Start, Power ON, Reset



;-----------------------------------------------------------------------


.org 3

	rjmp	interrupt

	rjmp	reset
reset:	ldi	r16,hi8(RAMEND)
	out	SPL,r16
	ldi	r16,lo8(RAMEND)
	out	SPH,r16
	ldi	r16,0b11111111
	out	DDRB,r16
	
	ldi	r16,255	;compare value
	out	OCR2,r16
	ldi	r16,0b00100010	;CTC - PRS 8
	out	TCCR2,r16
	ldi	r16,0b10000000	;Interrupt enable
	out	TIMSK,r16
	sei		;global int. enable
	ldi	r17,0b00000000
	ldi	r18,0b11111111
	;Hier Init-Code eintragen.
;------------------------------------------------------------------------

mainloop:	wdr


	rjmp	mainloop

interrupt:
;toggle Port B
	in	r16,PINC
	ori	r16,255
	breq	interrupt1
	out	PORTB,r18
interrupt1:
	out	PORTB,r17
interrupt2:
	reti

[bax]

Hi,

zwei Sachen fallen mir da auf:

1. Du springst mit Deinem ersten Befehl sofort in die Interruptroutine, und beim Reti weiß der Prozessor nicht, wohin er zurückspringen soll. Die Reihenfolge wie im ersten Post ist da schon richtig.

2. bei der Definition des Stackpointers hast Du SPL und SPH vertauscht. Das war auch schon mal richtiger im ersten Beispiel

Ergo, ich weiß auch nicht, warum Dein erstes Beispiel nicht geht ^^

greetz Rajko

[wkrug]

Probier mal den CODE für AVR Studio 4.
Dein Code schaltet zwar Portb kurz ein aber dann sofort wieder aus!
Der Interrupt wird also durchlaufen, nur Du merkst ausser einem sehr kurzen Impuls an PORTB nichts davon. Dein Interrupt wird bei einer Quarzfrequenz von 4MHz alle 512 µsec aufgerufen, was einer Frequenz von ca. 1000 Hz entspricht.
Ich hab auch noch die verwendeten Register auf dem Stack gesichert.
PORTB,3 has Du anscheinend mit einer Sonderfunktion belegt, der ist bei mir dauerhaft 0 im simulator!

.include    "m8def.inc"


;------------------------------------------------------------------------
;Reset and Interrupt vector             ;VNr.  Beschreibung

;Start, Power ON, Reset



;-----------------------------------------------------------------------
.cseg
.org 0

	rjmp   reset

.cseg
.org 3

   rjmp   interrupt

   
reset:   ldi   r16,low(RAMEND)
   out   SPL,r16
   ldi   r16,high(RAMEND)
   out   SPH,r16
   ldi   r16,0b11111111
   out   DDRB,r16
   
   ldi   r16,255   ;compare value
   out   OCR2,r16
   ldi   r16,0b00100010   ;CTC - PRS 8
   out   TCCR2,r16
   ldi   r16,0b10000000   ;Interrupt enable
   out   TIMSK,r16
   sei      ;global int. enable
   ldi   r17,0b00000000
   ldi   r18,0b11111111
   ;Hier Init-Code eintragen.
;------------------------------------------------------------------------

mainloop:   wdr


   rjmp   mainloop

interrupt:
;toggle Port B
	PUSH r16
	IN R16,SREG
	PUSH r16
   	PUSH r18
   	LDI r18,0xFF
	In   r16,PORTB
   	EOR   r16,r18
   	out   PORTB,r16
	POP r18
	POP r16
	OUT SREG,r16
	POP r16
   reti

[The Man]

NICHT SCHON WIEDER EIN USERPROBLEM!!!!!!!!!!!

Also ich hab´s jetzt und der Fehler lag in meiner Bedienung vom AVR Studio.
Man muss den Code eben erst "build"-en bevor man ihn brennt

Und danke, an alle, die was geschriben haben.

The Man

[wkrug]

Manchmal kann ich es wirklich nicht verstehn -

Da arbeitet man mit AVR Studio und nutzt den Simulator nicht, lieber ärgert man sich tagelang mit irgendwelchen lapidar Problemen rum, anstatt das fehlerhafte Stück Code mal im Simulator zu testen.

Hättest Du auf meinen 1sten Post hin deinen Code getestet, hättest Du ihn auf jeden Fall "builden" müssen und das Problem wäre gegessen.

Aber manche brauchen halt "Die harte Tour"

Sicher - der Simulator ist nicht perfekt.
Falsch eingestellte Fuse Bits können nicht erkannt werden.
Die Simulation von Datenaustausch über Peripherieschnittstellen (SPI, seriell, TWI) ist schwierig bis unmöglich.

Nichts destotrotz ist der Simulator ein mächtiges Werkzeug um einen Quellcode zu debuggen, aber sehr viele Leute nutzen das einfach nicht, wie hier einige Posts beweisen !

Ich progge jetzt seit ein paar Monaten in C (Codevision AVR) und nutze auch hier den Simulator vom Studio zum debuggen der Software.
Das klappt vorzüglich und ich krieg sehr oft eine sofort laufende Software in den Controller.

Sicher ist ein JTAG Hardware Debugger noch besser, aber mein schmales Hobby Budget gestattet so eine Anschaffung halt nicht.
Ausserdem ist die Anzahl der ATMEL- Controller mit JTAG Interface sehr Übersichtlich.

[The Man]

Ist ja nicht so, dass ich den Simulator nicht genutzt hätte.
Ich hab mich nur eben gewundert, dass es da lief und auf dem AVR nicht.

[wkrug]

Das wundert mich aber.
Wenn man "built" macht wird doch das .hex File neu generiert.
Oder hast Du dann immer wieder eine alte umbenannte Variante in den Chip eingespielt?
Das läuft dann unter der Rubrik "blöd gelaufen" und ich entschuldige mich hiermit für meine Äußerungen.