ISR geht nicht mehr in Atmel Studio 7 ?

Hier noch der Code, die Frage kommt eh.

1

#define F_CPU        20000000UL

2

3

#include <avr/io.h>

4

#include <avr/interrupt.h>

5

6

int main(void)

7

{

8

  CPU_CCP = 0xD8;

9

  CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;

10

  CPU_CCP = 0xD8;

11

  CLKCTRL_MCLKCTRLB = 0;

12

13

  CPU_CCP = 0xD8;

14

  WDT.CTRLA = 0;

15

16

  PORTB.DIR = 0b11111110;

17

18

  //Für den Timer (interrupt)  (1 kHz)

19

  TCD0.CMPBCLR = 625;

20

  TCD0.INTCTRL = TCD_OVF_bm;

21

  TCD0.CTRLB = TCD_WGMODE_ONERAMP_gc;

22

  TCD0.CTRLA = (TCD_CLKSEL_20MHZ_gc | TCD_CNTPRES_DIV32_gc | TCD_SYNCPRES_DIV1_gc | TCD_ENABLE_bm);

23

24

  sei();

25

26

    while (1) 

27

    {

28

    }

29

}

30

31

32

ISR(TCD0_OVF_vect)

33

{

34

  PORTA.OUT ^= (1<<PIN3_bp);

35

  TCD0.INTFLAGS = TCD_OVF_bm;

36

}

Markus M. schrieb:

Tiny1614

Könnte das Problem sein. Hast du mal geschaut, ob der von deiner Studio-Version unterstützt wird?

Oliver

Oliver S. schrieb:

Markus M. schrieb:

Tiny1614

Könnte das Problem sein. Hast du mal geschaut, ob der von deiner Studio-Version unterstützt wird?

Oliver

Ich nutze den in ca. 60 Projekten. Die ganzen Projekte wo der drin ist, da funktioniert es. Kopiere ich dieses Projekt geht das kopierte nicht mehr.... Strange oder?

Ich habe die neuste Version Microchip Studio. Wenn ich ein neues Projekt anlege wird mir der Tiny1614 ja auch aufgeführt. Ich habe es vorhin deinstalliert und neuinstalliert sowie PC neustart. Das ist es auch nicht.

Es liegt auch nicht am verwendeten CPU Typ. Ich hatte gerade mal mit anderen getestet (Tiny85, Mega328P, Xmega) es ist überall das gleiche. sei bleibt rot unterstrichen und ISR wird orange wie eine Funktion. Obowhl die avr/interrupt.h eingebunden ist.

HÄ?! Ich kapier das nicht.

Um genau zu sein kommt bei sei oder cli folgende Info wenn man mit der Maus drüber geht:

Unrecognized symbol. ALT+G to jump to a guess, see a list of several, or let IntelliSense try.

Zeige mal die Meldungen - in "meinem Microchip-Studio" geht es ohne Probleme.

.LSS sieht auch gut aus.

Hugo H. schrieb:

Zeige mal die Meldungen - in "meinem Microchip-Studio" geht es ohne Probleme.

Exakt wie bei dir. Das kompilieren geht ja auch. Aber auch wie bei dir, das ISR ist orange und das sei(); rot unterstrichen - ohne Referenz. Kompilieren geht. Spiele ich es auf den Chip, geht es nicht.

Ich muss aber eine Korrektur machen: Seit der Deinstallation, PC Neustart, Neuinstallation, PC Neustart geht es wieder alles. Crazy.

Scheinbar braucht die "Intellisense-Unterstützung" noch etwas "Reife" ... :-)

Hugo H. schrieb:

Scheinbar braucht die "Intellisense-Unterstützung" noch etwas "Reife" ... :-)

Irgendwie geht das gar nicht. Jetzt ging es. Anderes Tiny1614 Projekt kompiliert. Dann wieder zu dem Projekt. Jetzt geht das wieder nicht mehr. Code läuft erfolgreich durch, auf den Chip gespielt keine IRQ funktionieren. Ich deinstalliere das später noch einmal und erneut installieren wenn das dann wieder geht, mache ich die Software fertig und gehe nie wieder an das Projekt. Ich kapier das hier nicht

PORTA.OUT ^= (1<<PIN3_bp);

PORTA.OUTTGL = PIN3_bm;

Außerdem muss OUTPUT sein.

Georg M. schrieb:

PORTA.OUT ^= (1<<PIN3_bp);

PORTA.OUTTGL = PIN3_bm;

Außerdem muss OUTPUT sein.

Das stimmt nicht. OUT ist korrekt. Es gibt auch OUTTGL, aber das muss man nicht nehmen, Xor geht es genauso. Was würde man nur sonst bei den Megas machen die das nicht so schön in STrukturen haben wie die neuen Tiny, Mega und XMEGA :)

S. Landolt schrieb:

Das ist zwar so, ändert aber nichts am zweiten Einwand - wo steht das Setzen auf OUTPUT für PORTA.Pin3?: 'OUT ... This configuration only has an effect when the output driver (PORTx.DIR) is enabled for the corresponding pin.'

Es steht oben ganz oben drin.

PORTB.DIR = xyz

Wie gesagt, die Software ist FEHLERFREI. Es geht NICHT. Auch nach neuinstallation, PC neustart usw. Das Programm von oben läuft nicht auf dem Chip ich kapiere nicht was das Problem ist.

Kaj schrieb:

Markus M. schrieb:

die Software ist FEHLERFREI.

Starke Worte. Du scheinst nicht viel Erfahrung im Bereich Software zu haben.

Ja dann sag mir bitte wo der Fehler liegt. Du weißt ja scheinbar bescheid. Spiele ich die Software wie unten angegeben auf, habe ich an PA2 das toggeln in hoher Frequenz. Die ISR macht nichts.

Gestern lief genau das gleiche Programm auch mit der ISR. Dann wieder nicht mehr. Den gleichen Code vom Timer nutze ich in 60 anderen Tiny1614 Projekten ohne Fehler.

Wo ist der Fehler ?!?!

1

#define F_CPU        20000000UL

2

3

#include <avr/io.h>

4

#include <avr/interrupt.h>

5

6

int main(void)

7

{

8

  CPU_CCP = 0xD8;

9

  CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;

10

  CPU_CCP = 0xD8;

11

  CLKCTRL_MCLKCTRLB = 0;

12

13

  CPU_CCP = 0xD8;

14

  WDT.CTRLA = 0;

15

16

  PORTA.DIR = 0xFF;

17

  PORTB.DIR = 0b11111110;

18

19

  //Für den Timer (interrupt)  (1 kHz)

20

  TCD0.CMPBCLR = 625;

21

  TCD0.INTCTRL = TCD_OVF_bm;

22

  TCD0.CTRLB = TCD_WGMODE_ONERAMP_gc;

23

  TCD0.CTRLA = (TCD_CLKSEL_20MHZ_gc | TCD_CNTPRES_DIV32_gc | TCD_SYNCPRES_DIV1_gc | TCD_ENABLE_bm);

24

25

  sei();

26

27

  while (1)

28

  {

29

    PORTA.OUT ^= (1<<PIN2_bp);

30

  }

31

}

32

33

34

ISR(TCD0_OVF_vect)

35

{

36

  PORTA.OUT ^= (1<<PIN3_bp);

37

  TCD0.INTFLAGS = TCD_OVF_bm;

38

}

Noch ein Nachtrag, aus Verzweifelung habe ich jetzt mal in die Loop folgendes gemacht:

1

if (TCD0.INTFLAGS)

2

    {

3

      PORTA.OUT ^= (1<<PIN2_bp);

4

      TCD0.INTFLAGS = TCD_OVF_bm;

5

    }

Ich bekomme dann ein 1khz Signal an PA2. Das heißt die Timerhardware funktioniert. Entweder werden keine ISR global aktiviert über das sei() oder er sieht die ISR Routine im Compiler nicht.

In das ISR geht er auf jeden Fall nicht, auch im Debug erreicht er die nicht. Wie kann ich prüfen ob sei global aktiviert ist, kann man da ein Bit abfragen? Ich habe eher das Gefühl das der Compiler aber die ISR nicht sieht.

Hier mal der Auszug aus dem Dissembly. Ist das korrekt das da "no source file" steht?!

1

--- No source file -------------------------------------------------------------

2

00000069  LDD R24,Z+4    Load indirect with displacement 

3

0000006A  EOR R24,R25    Exclusive OR 

4

0000006B  STD Z+4,R24    Store indirect with displacement 

5

0000006C  RJMP PC-0x0003    Relative jump 

6

0000006D  PUSH R1    Push register on stack 

7

0000006E  PUSH R0    Push register on stack 

8

0000006F  IN R0,0x3F    In from I/O location 

9

00000070  PUSH R0    Push register on stack 

10

00000071  CLR R1    Clear Register 

11

00000072  PUSH R24    Push register on stack 

12

00000073  PUSH R25    Push register on stack 

13

00000074  PUSH R30    Push register on stack 

14

00000075  PUSH R31    Push register on stack 

15

00000076  LDI R30,0x00    Load immediate 

16

00000077  LDI R31,0x04    Load immediate 

17

00000078  LDD R25,Z+4    Load indirect with displacement 

18

00000079  LDI R24,0x08    Load immediate 

19

0000007A  EOR R24,R25    Exclusive OR 

20

0000007B  STD Z+4,R24    Store indirect with displacement 

21

0000007C  LDI R24,0x01    Load immediate 

22

0000007D  STS 0x0A8D,R24    Store direct to data space 

23

0000007F  POP R31    Pop register from stack 

24

00000080  POP R30    Pop register from stack 

25

00000081  POP R25    Pop register from stack

Ich habe das Problem gefunden. unglaublich. Es war das neue Tiny_DFP installiert (Version 2.xx). Ich habe es auf 1.3 gesetzt im General unter Assembler und Directions unter AVR/GNU C Compiler und schon geht mein Code wieder wie er soll!

$(PackRepoDir)\atmel\ATtiny_DFP\1.3.172\include

Verstehe tu ich das zwar dennoch nicht weil es mit dem neuen ja auch gehen sollte? Zumindest geht es aber nun

Edit: Es ging 1x. Erneuter Compilierung geht der unveränderte Code wieder nicht...

CPU_CCP = 0xD8; CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;

Nur um ganz sicher zu gehen, dass das Timing eingehalten wird, evtl. in Betracht ziehen, stattdessen:

1

_PROTECTED_WRITE (CLKCTRL_MCLKCTRLA, CLKCTRL_CLKSEL_OSC20M_gc);

und dito für die anderen CCP-geschützten Register.

Das ist ein Makro innerhalb von avr/io.h, das adäquaten (inline Assembly) Code erzeugt.

Johann L. schrieb:

CPU_CCP = 0xD8; CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;

Nur um ganz sicher zu gehen, dass das Timing eingehalten wird, evtl. in Betracht ziehen, stattdessen:

1

> _PROTECTED_WRITE (CLKCTRL_MCLKCTRLA, CLKCTRL_CLKSEL_OSC20M_gc);

2

>

und dito für die anderen CCP-geschützten Register.

Das ist ein Makro innerhalb von avr/io.h, das adäquaten (inline Assembly) Code erzeugt.

Leider kein Unterschied. Das CCP vorweg (siehe Code) sollte das gleiche machen das man protected schreibt. Ich habe ja auch die 20Mhz/2 in der Loop vom Ausgangspin Toggle und auch bei Loop-Abfrage mit dem Timer 1khz. Das System läuft und passt. Die ISR Routine sieht der irgendwie im Compiler nicht

S. Landolt schrieb:

wo steht das Setzen auf OUTPUT für PORTA.Pin3?

Es steht oben ganz oben drin. PORTB.DIR = xyz Wie gesagt, die Software ist FEHLERFREI.

In der ISR steht

PORTA.OUT ^= (1<<PIN3_bp);

Könnten Sie das einem ATtiny1614-Nichtkenner erläutern?

Was genau jetzt?

PORTx.DIR setzt das Register ob Eingang oder Ausgang. Bei Tiny/Mega früher war es das normale DDRx. Das ist einfach nur in Strukturen wie bei den Xmegas was ich deutlich besser finde.

PORTx.OUT ist wie früher das PORTx. Also Zugriff ob Low or High. Es gibt noch Strukturen fürs direkte Setzen (PORTx.CLRSET oder PORTx.OUTSET) ich nutze aber primär OUT und mache dann ganz normal damit setzen, löschen oder togglen. Die XOR Verknüpfung dort hat nichts mit den Tiny zu tun ist ganz normale Toggle per Bitmanipulation.

Sonst haben die Pins eigene Strukturen zum aktivieren für Pullup oder Pin Interrupt usw. das geht dann mit PORTx.PINy_CNTR

S. Landolt schrieb:

Was genau jetzt?

Meine Frage ist, ob es da eine interne Korrelation zwischen PORTA und PORTB gibt.

Setzen tu ich nur Pin3 von PortA in der ISR. PORTB ist da nicht. ich habe nur bei er Init PORTA + PORTB komplett als Ausgang geschaltet außer PB0 als Eingang.

PORTA.DIR = 0xFF; PORTB.DIR = 0b11111110;

ISR geht nicht mehr in Atmel Studio 7 ?

Probiere es dann doch mit der MPLAB X IDE.

Aber ich bekomme keine Probleme mit dem Microchip Studio und seinem Compiler. Die LED blinkt. Und sogar sehr schnell.

1

/*-----------------------------------------------

2

   ATtiny824 TCB0 50ms periodic interrupt

3

4

     VDD 1|‾‾‾‾‾‾‾|14 GND 

5

     PA4 2|       |13 PA3 ---- LED

6

     PA5 3|       |12 PA2

7

     PA6 4|       |11 PA1 

8

     PA7 5|       |10 UPDI

9

     PB3 6|       | 9 PB0 

10

     PB2 7|_______| 8 PB1 

11

12

  2MHz/2/50000 = 20Hz    T = 50ms

13

---------------------------------------------*/

14

15

#include <avr/io.h>

16

#include <avr/interrupt.h>

17

18

ISR(TCB0_INT_vect)

19

{

20

  PORTA.OUTTGL = PIN3_bm;         // toggle PA3

21

  TCB0.INTFLAGS = TCB_CAPT_bm;    // clear TCB0 interrupt flag

22

} 

23

24

int main(void)

25

{

26

  _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_10X_gc | CLKCTRL_PEN_bm);    // Main Clock 2MHz

27

28

  PORTA.DIRSET = PIN3_bm;                              // PA3 as output

29

30

  TCB0.CCMP = 0xC350;                                  // Timeout value (50000)

31

  TCB0.CTRLA = TCB_CLKSEL_DIV2_gc | TCB_ENABLE_bm;     // TCB0 Clock 1MHz, enable TCB0

32

  TCB0.INTCTRL = TCB_CAPT_bm;                          // Enable Capture or Timeout interrupt

33

34

  sei();                                               // Enable Global Interrupts

35

36

  while(1) 

37

  {

38

   ;

39

  }

40

}

S. Landolt schrieb:

Gestern lief genau das gleiche Programm auch mit der ISR. Dann wieder nicht mehr. Den gleichen Code vom Timer nutze ich in 60 anderen Tiny1614 Projekten ohne Fehler.

Allmählich entsteht der Verdacht, dass Irgendwas/wer Programmversionen durcheinanderwirft. Denn das ursprüngliche Programm kann so wie gezeigt nie gelaufen sein, auch nicht nach einer Neuinstallation:

Seit der Deinstallation, PC Neustart, Neuinstallation, PC Neustart geht es wieder alles. Crazy.

Verstehe ich nicht ganz. Was genau ist gemeint? Das Programm lief per Timer im ISR. Und das Programm was ich da gepostet habe in einem weiter unterem Kommentar, das lief und läuft jetzt nicht mehr. Er springt einfach nicht in die ISR. Als würde die gar nicht existieren.

S. Landolt schrieb:

Verstehe ich nicht ganz. Was genau ist gemeint?

? - Was ist an dem Satz "Denn das ursprüngliche Programm kann so wie gezeigt nie gelaufen sein" nicht zu verstehen? Dort wird PORTA.DIR nicht gesetzt, trotzdem soll PORTA.OUT funktioniert haben, nach einer Neuinstallation - das passt nicht zusammen.

Verstehe. das ursprüngliche da fehlte PORTA.DIR = 0xFF. Das war drin. ich hatte mal die Pins gewechselt. Nicht verunsichern dadurch. Das programm wie gepostet geht natürlich nicht. unabhängig davon muss er ja in den Breakpoint springen und das tut er halt auch nicht.

Georg M. schrieb:

ISR geht nicht mehr in Atmel Studio 7 ?

#include <avr/io.h> #include <avr/interrupt.h>

ISR(TCB0_INT_vect) { PORTA.OUTTGL = PIN3_bm; // toggle PA3 TCB0.INTFLAGS = TCB_CAPT_bm; // clear TCB0 interrupt flag }

int main(void) { _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_10X_gc | CLKCTRL_PEN_bm); // Main Clock 2MHz

PORTA.DIRSET = PIN3_bm; // PA3 as output

TCB0.CCMP = 0xC350; // Timeout value (50000) TCB0.CTRLA = TCB_CLKSEL_DIV2_gc | TCB_ENABLE_bm; // TCB0 Clock 1MHz, enable TCB0 TCB0.INTCTRL = TCB_CAPT_bm; // Enable Capture or Timeout interrupt

sei(); // Enable Global Interrupts

while(1) { ; } } [/c]

Jop, genau das gleiche wie bei meinem programm. Es passiert halt nichts ?!

HILFE!!

Ich bin am verzweifeln. Kannst du mir bitte noch einmal deine Settings des Projektes - oder noch besser das ganze Projekt mal hochladen als ZIP

Markus M. schrieb:

Es passiert halt nichts

Und keine Fehlermeldung?

Es gibt nämlich Differenzen:

tinyAVR® 0,1: TCB_CLKSEL_CLKDIV2_gc tinyAVR® 2 : TCB_CLKSEL_DIV2_gc

Georg M. schrieb:

Markus M. schrieb:

Es passiert halt nichts

Und keine Fehlermeldung?

Es gibt nämlich Differenzen:

tinyAVR® 0,1: TCB_CLKSEL_CLKDIV2_gc tinyAVR® 2 : TCB_CLKSEL_DIV2_gc

Ich hatte das angepasst. (1<<2)

Markus M. schrieb:

Kannst du mir bitte noch einmal deine Settings des Projektes - oder noch besser das ganze Projekt mal hochladen als ZIP

ATtiny824 TCB periodic interrupt

S. Landolt meint (wie Du sicher auch weisst) das:

Markus M. schrieb:

CPU_CCP = 0xD8; WDT.CTRLA = 0;

PORTB.DIR = 0b11111110;

//Für den Timer (interrupt) (1 kHz) TCD0.CMPBCLR = 625; TCD0.INTCTRL = TCD_OVF_bm;

Da wird nur PORTB gesetzt - habe ich nicht darauf geachtet, weil Du ja von einem Compilier-Problem geschrieben hast. Das gibt es nach wie vor bei mir nicht - auch die ISR wird korrekt angesprungen (wie zu sehen ist auch im internen Debugger) es passiert halt logischerweise nichts am PIN. Das Interrupt-Flag muss man übrigens nicht zurücksetzen, das macht der Interrupt-Handler.

Hugo H. schrieb:

S. Landolt meint (wie Du sicher auch weisst) das: Da wird nur PORTB gesetzt - habe ich nicht darauf geachtet, weil Du ja von einem Compilier-Problem geschrieben hast. Das gibt es nach wie vor bei mir nicht - auch die ISR wird korrekt angesprungen (wie zu sehen ist auch im internen Debugger) es passiert halt logischerweise nichts am PIN. Das Interrupt-Flag muss man übrigens nicht zurücksetzen, das macht der Interrupt-Handler.

Genau, etwas weiter im Verlauf ist das PRogramm gepostet, womit ich nur gearbeitet habe. Ich habe das obere korrigiert.

Georg M. schrieb:

Markus M. schrieb:

Kannst du mir bitte noch einmal deine Settings des Projektes - oder noch besser das ganze Projekt mal hochladen als ZIP

ATtiny824 TCB periodic interrupt

mit MPLAB geht es auch nicht. Habe dort auch extra kein GNU gewählt. Ich tausche gleich mal den Chip ob es an dem liegt. Kann doch nicht sein hier.

Ich muss mich korrigieren - beide Versionen funktionieren im internen Debugger, eine halt mit "undefinierter PORT-Einstellung" (im tri-state?).

HEUREKA es geht!

Nachdem ich den Chip getauscht habe, ging es. Software drauf, ging. Dann meine echte Firmware (das oben ist ja nur Testprogramm) ging wieder nicht. Chip wieder runter, neuer drauf. Gleiches. Ging wieder. Dann habe ich die Fuses verglichen und warum auch immer ist bei BOOTEND = 0x02 reingekommen das muss auf 0x00 sein, wie das sonst auch in meinen projekten überall der Fall ist.

Sobald das auf 0x02 ist, geht es nicht mehr. Wenn das auf 0x00 ist, geht es wie gewünscht!

S. Landolt schrieb:

Bei einem ATtiny1614, stimmt das? Kann ich aus dem Datenblatt nicht herauslesen.

Da bin ich wohl "XMEGA-versaut".

Ich so auch nicht, im Debugger passiert es nicht und einen Tiny1614 habe ich nicht - nehme es also zurück.

Hugo H. schrieb:

S. Landolt schrieb:

Bei einem ATtiny1614, stimmt das? Kann ich aus dem Datenblatt nicht herauslesen.

Da bin ich wohl "XMEGA-versaut".

Ich so auch nicht, im Debugger passiert es nicht und einen Tiny1614 habe ich nicht - nehme es also zurück.

Bei den alten Mega/Tinys macht das der Handler.

Bei Xmega muss man es selber machen Bei den neuen Tiny0,1,2 oder Mega0,1 Series muss man es auch selber machen (zumindest hier noch so in Erinnerung als ich damals als die rauskamen meine Libs geschrieben habe für das ganze Peripherie Zeug)

S. Landolt schrieb:

Hugo Hurtig meinte um 14:54:

Das Interrupt-Flag muss man übrigens nicht zurücksetzen, das macht der Interrupt-Handler.

Bei einem ATtiny1614, stimmt das? Kann ich aus dem Datenblatt nicht herauslesen.

Soweit ich es in Erinnerung habe muss man bei den Tiny0,1,2 Series das selber machen?

Markus M. schrieb:

Bei Xmega muss man es selber machen

Nein, siehe Bild