AVR Studio 4, Assembler und Timer/Watchdog

[Stephan E. (loetzinn02)]

Hallo in die geschätzte Expertenrunde,

vielleicht kann mir jemand auf die Sprünge helfen. Derzeit simuliere ich 
einen ATTiny13A (default-Fuses) im AVR Studio 4.16.628 unter Linux mit 
Wine.
Dabei ist mir eine Anomalie aufgefallen, für die ich keine Erklärung 
habe.

Anbei voneinander nur leicht abweichende Assembler-Codes (die vielen 
Leerzeilen werden hier scheinbar vom Forums-Editor eingefügt, weiß nicht 
wo die herkommen. Im Original sind die nicht vorhanden).

Der eine nutzt drei Interrupts: einmal beim Match von OC0B im Timer0, 
dann beim Überlauf des Timers und als dritten den Watchdog in der 
Interrupt-only-Variante. Das funktioniert erst mal wie erwartet. Der 
OC0B-Match-Interrupt wird ausgelöst, danach der erste Timer-Überlauf. 
Der passende Interrupt wird auch hier ausgelöst und abgearbeitet - dann 
bleibt der Timer0 einfach auf Null stehen und das Programm verbleibt in 
der Endlosschleife, der Watchdog springt niemals an.

Darunter eine leicht abgewandelte Programmversion, die auf dem Vergleich 
OC0B verzichtet, alles andere ist gleich. Hier ein ähnliches Verhalten: 
Der erste Interrupt beim Timerüberlauf wird ausgelöst und abgearbeitet - 
der Timer bleibt auch jetzt bei Null stehen und läuft nicht mehr.
Allerdings funktioniert im Gegensatz zur ersten Variante jetzt der 
Watchdog, der wie erwartet etwa alle 32 simulierten Millisekunden 
auslöst.

Hat zufällig jemand eine Erklärung?


Variante A: Drei Interrupts

.nolist
.include "tn13adef.inc" ; Define device ATtiny13A
.list
.def sreg_bak = R15 
.def rmp = R16 
.dseg
.org SRAM_START
.cseg
.org 0x0000
rjmp Main ; Reset vector
reti ; INT0
reti ; PCI0
rcall isr_timer_overflow ; OVF0
reti ; ERDY
reti ; ACI
reti; OC0A
rcall isr_oc0b; OC0B
rcall isr_watchdog ; WDT
reti ; ADCC

init_watchdog:
 wdr
 in rmp, MCUSR
 andi rmp, (0xff - (1<<WDRF))
 out MCUSR, rmp
 in rmp, WDTCR
 ori rmp, (1<<WDTIE)|(1<<WDP0) ; Interrupt-only und prescaler 32ms
 out WDTCR, rmp
 ret

init_timer0:
 push rmp
 ldi rmp, 220
 out OCR0B, rmp
 ldi rmp,(1<<WGM01)
 out TCCR0A, rmp
 ldi rmp, (1<<CS01)
 out TCCR0B, rmp
 ldi rmp, (1<<TOIE0)|(1<<OCIE0B)
 out TIMSK0, rmp
 pop rmp
 ret


Main:
 ldi rmp,Low(RAMEND)
 out SPL,rmp 
 rcall init_watchdog
 rcall init_timer0
 sbi DDRB,1
 sei 

Loop:
 nop
 rjmp Loop


isr_timer_overflow:
 in sreg_bak, SREG
 cbi PORTB,1
 out SREG, sreg_bak
 reti

isr_oc0b:
 reti

Variante B: Zwei Interrupts

.nolist
.include "tn13adef.inc"
.list
.def sreg_bak = R15
.def rmp = R16
.dseg
.org SRAM_START
.cseg
.org 0x0000

rjmp Main 
reti ; INT0
reti ; PCI0
rcall isr_timer_overflow ; OVF0
reti ; ERDY
reti ; ACI
reti; isr_oc0a; OC0A
reti; rcall isr_oc0b; OC0B
rcall isr_watchdog ; WDT
reti ; ADCC

init_watchdog:
 wdr
 in rmp, MCUSR
 andi rmp, (0xff - (1<<WDRF))
 out MCUSR, rmp
 in rmp, WDTCR
 ori rmp, (1<<WDTIE)|(1<<WDP0) ; prescaler 32ms
 out WDTCR, rmp
 ret

init_timer0:
 push rmp
 ldi rmp, 220
 out OCR0B, rmp
 ldi rmp,(1<<WGM01)
 out TCCR0A, rmp
 ldi rmp, (1<<CS01)
 out TCCR0B, rmp
 ldi rmp, (1<<TOIE0)
 out TIMSK0, rmp
 pop rmp
 ret


Main:
 ldi rmp,Low(RAMEND)
 out SPL,rmp
 rcall init_watchdog
 rcall init_timer0
 sbi DDRB,1
 sei 

Loop:
 nop
 rjmp Loop


isr_timer_overflow:
 in sreg_bak, SREG
 cbi PORTB,1
 out SREG, sreg_bak
 reti

isr_watchdog:
 in sreg_bak, SREG
 sbi PORTB,1
 out SREG, sreg_bak
 reti

[Wastl (hartundweichware)]

Stephan E. schrieb:
> Hallo in die geschätzte Expertenrunde

Fuck! Kannst du lesen und das freundlicherweise befolgen?

"Längerer Sourcecode" ist wenn es mehr als eine Seite ist.

[S. L. (sldt)]

Ganz auf die Schnelle:

...
reti; OC0A
rcall isr_oc0b; OC0B
rcall isr_watchdog ; WDT
reti ; ADCC

mutet seltsam an, soll das nicht 'rjmp' heißen?

[Stephan E. (loetzinn02)]

Wastl schrieb:
> Fuck! Kannst du lesen und das freundlicherweise befolgen?

Sorry, habe ich wohl übersehen. Und so lange ist's ja auch wieder nicht.

[Stephan E. (loetzinn02)]

S. L. schrieb:
> rcall isr_watchdog ; WDT
> reti ; ADCC
> mutet seltsam an, soll das nicht 'rjmp' heißen?

Habe ich mal getestet, scheint beides zu funktionieren. Aber nachdem 
auch im Tutorial überall rjmp verwendet wird, werde ich das künftig auch 
tun. Danke für den Hinweis.
Ansonsten hat sich leider nichts geändert - der Timer0 bleibt nach dem 
ersten Überlauf einfach stehen.

[S. L. (sldt)]

Wieder auf die Schnelle:

> scheint beides zu funktionieren

Kann ich mir nicht vorstellen - in der 1. Version zum Beispiel wird ja 
grundsätzlich nach isr_oc0b auch noch isr_watchdog abgearbeitet.

Ansonsten: Simulator & Interrupts - ob das immer funktioniert? Da gab es 
mal Beiträge ...
  Und warum nicht der ATtiny85 - den könnte ich hier gegebenenfalls 
realiter laufen lassen.

[C-hater (c-hater)]

Stephan E. schrieb:

> Habe ich mal getestet, scheint beides zu funktionieren.

Nicht wirklich. Bei jedem Interrupt werden zwei Byte auf dem Stack 
"verbraucht". Ist nur eine Frage der Zahl der Interrupts, bis der Stack 
überlauft (bzw. eigentlich: unterläuft). Das sinnlose (und am Ende 
tödliche) Wachsen des Stack sollte sich im Simulator wirklich sehr gut 
verfolgen lassen.

> Ansonsten hat sich leider nichts geändert - der Timer0 bleibt nach dem
> ersten Überlauf einfach stehen.

Das kann nicht sein. Dem Timer ist der Stack egal, dem Timer ist 
überhaupt egal, was die MCU tut. Einmal gestartet, läuft der einfach. Es 
sei denn, die MCU hält ihn an. Dafür gibt es aber keinen Code.

Und übrigens: in deiner Variante A gibt es darüber hinaus auch keinen 
Code für isr_watchdog. Das dürfte also nichtmal assemblierbar sein...

[Falk B. (falk)]

S. L. schrieb:
> ...
> reti; OC0A
> rcall isr_oc0b; OC0B
> rcall isr_watchdog ; WDT
> reti ; ADCC
> mutet seltsam an, soll das nicht 'rjmp' heißen?

In der Tat.

[S. L. (sldt)]

> Wachsen des Stack

?
Zurückgekehrt wird doch immer, oder? Nur an irrwitzigen Stellen.

[C-hater (c-hater)]

S. L. schrieb:

> Ansonsten: Simulator & Interrupts - ob das immer funktioniert?

Jedenfalls bezüglich der MCU habe ich beim SimulatorV2 noch nie 
Gegenteiliges feststellen können.

Bugs gibt es aber reichlich in der Simulation der Peripherie und auch 
Peripherie, die praktisch garnicht simuliert wird. Bei letzterem kann 
man natürlich ewig auf das Auftreten der entsprechende Interrupts 
warten. Es werden keine erfolgen...

Wie auch immer, das Entscheidende scheint mir zu sein, dass angeblich 
der Timer stoppt. Das tut er natürlich nicht. Weder in der Simulation 
noch in der Realität. Ich tippe mal auf einen Bedienfehler. 
Möglicherweise ausgelöst durch einen Anzeigefehler, der durch Wine 
verursacht wird.
Ich kann mich erinnern, dass ich auch mal versucht habe, das Studio4 
unter Wine zu betreiben, das dann aber wegen extremer Anzeigefehler 
schon im Editor  schnell wieder aufgegeben habe. Bis zum Einsatz des 
Simulators bin ich also unter Wine niemals gekommen.

[C-hater (c-hater)]

S. L. schrieb:
>> Wachsen des Stack
>
> ?
> Zurückgekehrt wird doch immer, oder?

Nicht im Simulator. Der kann Stack-Unterlauf diagnostizieren und hält 
dann an. Gibt aber natürlich dann auch eine ensprechende Fehlermeldung 
auf der Debugger-Console aus.

[S. L. (sldt)]

Nein, das meinte ich nicht, sondern: es gibt hier keinen Stack-Unterlauf 
- wo sollte der auch auftreten?

[C-hater (c-hater)]

S. L. schrieb:
> Nein, das meinte ich nicht, sondern: es gibt hier keinen Stack-Unterlauf
> - wo sollte der auch auftreten?

Es passiert folgendes:

IRQ:
- SREG_I wird gelöscht
- die Rücksprungadresse wird auf den Stack gelegt
- der Vektor wird angesprungen

Vektor:
- rcall legt legt erneut eine Rücksprungadresse auf den Stack
- springt das angegebene Ziel an

Ziel (ISR):
-wird abgearbeitet
-endet mit reti (setzt SREG_I, holt 1x Rücksprungadresse vom Stack)
-das ist die vom (falschen) rcall gesetzte Rücksprungadresse
-führt effektiv dazu, das der nächste Vektor in der Reihenfolge der
 Vektortabelle durchlaufen wird.

Und jetzt wird es spannend. Beim Overflow steht auf dem nächsten Vektor 
ein reti. Das holt die zweite Rücksprungadresse vom Stack (setzt das in 
diesem Fall bereits gesetzte SREG_I) und springt zur Rücksprungadresse. 
Alles gut hier, die Bilanz stimmt. Schwachsinn ist es trotzdem.

Aber, nun spiele mal selber durch, was bei OC0B passiert...

[S. L. (sldt)]

> Aber, nun spiele mal selber durch, was bei OC0B passiert...

Das, was ich bereits geschrieben hatte:

> in der 1. Version zum Beispiel wird ja grundsätzlich
> nach isr_oc0b auch noch isr_watchdog abgearbeitet.

Und anschließend wird bei 'reti ; ADCC' ins Hauptprogramm zurückgekehrt 
- also ich sehe nach wie vor keinen Stack-Unterlauf.

[C-hater (c-hater)]

S. L. schrieb:
>> Aber, nun spiele mal selber durch, was bei OC0B passiert...
>
> Das, was ich bereits geschrieben hatte:
>
>> in der 1. Version zum Beispiel wird ja grundsätzlich
>> nach isr_oc0b auch noch isr_watchdog abgearbeitet.

Wie kann das sein? isr_watchdog existiert in der "ersten Version" (vom 
TO als Version A bezeichnet) doch garnicht.

Was also steht auf diesem Vektor wirklich?

[S. L. (sldt)]

> isr_watchdog existiert in der "ersten Version" (vom
> TO als Version A bezeichnet) doch garnicht.

In der "Monitor-Version" nicht, das stimmt, aber in der "Anhang-Version" 
- war wohl ein copy&paste-Versehen von Stephan E.

[S. L. (sldt)]

an Stephan E.:

Zwei Anmerkungen (falls da Unkenntnis bestehen sollte):
 - 'reti' wird zwar mit "Return from interrupt" beschrieben, ist aber 
lediglich ein 'ret', welches zusätzlich das 'Global Interrupt Flag' in 
SREG setzt.
  - größere Programmblöcke können so auskommentiert werden:

/*
dies wird vorlaeufig stillgelegt:
disable_overflow:
 push rmp
 in rmp, TIMSK0
 andi rmp, (0<<TOIE0)
 out TIMSK0, rmp
 pop rmp
 ret
*/

[Falk B. (falk)]

Vielleicht der falsche Controller im Simulator eingestellt? Denn der 
wird nicht automatisch aus dem Editor übernommen.

[Falk B. (falk)]

Ich habs gerade mal probiert, der Timer bleibt nach dem ersten 
ISR-Aufruf im Simulator stehen!

[C-hater (c-hater)]

Falk B. schrieb:
> Ich habs gerade mal probiert, der Timer bleibt nach dem ersten
> ISR-Aufruf im Simulator stehen!

Welcher Simulator? V1 oder V2?

[Falk B. (falk)]

V2

[Falk B. (falk)]

Mit V1 gehts auch nicht.  Und das Interrupt-Flag wird verspätet gesetzt, 
zumindest in der Anzeige der IO Register, da läuft die ISR schon ;-)
Aber auch bei Prescaler 1 bleibt der Timer stehen. Ein Bug im 
AVR-Studio.

[C-hater (c-hater)]

Falk B. schrieb:

> Mit V1 gehts auch nicht.  Und das Interrupt-Flag wird verspätet gesetzt,
> zumindest in der Anzeige der IO Register, da läuft die ISR schon ;-)
> Aber auch bei Prescaler 1 bleibt der Timer stehen. Ein Bug im
> AVR-Studio.

Der V1-Simulator ist ziemlicher Rotz. Der bildet nichtmal die MCU 
vollständig korrekt ab. Der V2 hingegen tut wenigstens dies, hat aber 
auch immer noch ziemliche Mankos bezüglich der Peripherie. Für einen 
Tiny13 sollte es aber eigentlich reichen, der hat ja nun nicht sehr viel 
an Peripherie und im konkreten Fall ist nur Timer0 und Watchdog 
involviert.

Aber klar: Ein Bug im Simulator wäre definitiv möglich. Kann man am 
einfachsten dadurch umgehen, dass man halt echte Hardware verwendet...

[Stephan E. (loetzinn02)]

Zunächst mal vielen Dank für die Antworten.
Was ich daraus mitgenommen habe:
- ISRs werden ab sofort nur noch per rjmp aufgerufen, nicht mehr per 
rcall.
- Mehrzeilige Kommentare wie in z.B. c++ oder JavaScript möglich (wußte 
ich bei assembler tatsächlich noch nicht)
- Der Timer-stop könnte tatsächlich ein Bug sein - ein extra Dank an die 
Tester. Ggf. kann ich das ja mit einem extra Timer-init im Interrupt im 
Quellcode "umgehen", mal schau'n.

[C-hater (c-hater)]

Stephan E. schrieb:

> - Mehrzeilige Kommentare wie in z.B. c++ oder JavaScript möglich (wußte
> ich bei assembler tatsächlich noch nicht)

Der Avr-Asembler stellt (neben den C-Style-Kommentaren) auch eine 
C-Style Präprozessor zur Verfügung. Das erleichtert auch manches...

[Peter D. (peda)]

Stephan E. schrieb:
> Habe ich mal getestet, scheint beides zu funktionieren.

Als Assemblerprogrammierer sollte man schon die Bedeutung der einzelnen 
Befehle gelesen und verstanden haben. Sonst funktionieren Deine 
Programme nur zufällig bzw. meistens nicht.
Zwischen JMP und CALL besteht ein gewaltiger Unterschied.