AtMega162 resettet dauernd

[Chris (Gast)]

Gibt es irgendeinen Trick den ich nicht kenne warum mein Mega162 nicht 
startet ?
Mein ursprüngliches Programm war für einen AtMega8 hab es dann quasi 
genauso für den 162 übernommen .
Den Reset Pin habe ich nicht beschaltet Fuses stimmen  ?.
Hat jemand eine Idee ?

[Agent Provocateur (Gast)]

Chris schrieb:
> Hat jemand eine Idee ?

Ja.

[Chris (Gast)]

Und zwar ;-)

[Oliver J. (skriptkiddy)]

Warum hast du den Reset-Pin in der luft hängen?

[gonzo (Gast)]

Brown-Out Detection oder Watchdog aktiv?

[Chris (Gast)]

gonzo schrieb:
> Brown-Out Detection oder Watchdog aktiv?

Nein beides zum Test deaktiviert .5V liegen aber einwandfrei an .
Habe auch ein Display angeschlossen .Da sieht es aus als würde es 
ständig neustarten quasi wie bei watchdog zb -
Wie gesagt ist aber beides aus ?!.

[Karl H. (kbuchegg)]

Chris schrieb:
> Habe auch ein Display angeschlossen .Da sieht es aus als würde es
> ständig neustarten quasi wie bei watchdog zb -

Mit 'sieht so aus' kommt man nicht weiter.

Programm modifizieren:
Als erstes wird in main() ein Ausgang konfiguriert, eine LED 
eingeschaltet und eine halbe Sekunde gewartet. Danach LED wieder aus.

Und dann wird getestet:
ist die LED mehr oder weniger ständig an, erfolgt ein Dauerreset.
Ist sie überhaupt nie an, läuft der Prozessor erst gar nicht los
Ist sie nur einmal an und dann nie wieder, ist es irgendwas anderes.

[g457 (Gast)]

> Mein ursprüngliches Programm war für einen AtMega8 hab es dann quasi
> genauso für den 162 übernommen .

Wie genau ist 'quasi genauso'? Unverändert? Neu compiliert? Register 
angepasst (m8 und m162 sind nicht 'registerkompatibel')?

HTH

[g457 (Gast)]

Interrupttabelle angepasst?</ingrid>

[Karl H. (kbuchegg)]

Je nachdem wie es programmiert ist, sollte man auch die 
Konfigurationsregister und deren Bits vom Mega8 mit denen vom Mega162 
vergleichen.

Wenn sich Bits in ihrer Lage verschoben haben, dann kann man das schon 
so programmieren, das es zu einem Reset kommt. Nämlich dann wenn man 
mittels Binärschreibweise plötzlich einen ganz anderen Interrupt 
freigibt als ursprünglich beabsichtigt.

[Chris (Gast)]

Ja Interrupt war das Stichwort .Ich hatte einen Timer interrupt drin 
.Wieso der allerdings nicht richtig ist weiß ich auch gerade nicht .

//======================================================================

void initTimer0()
{
  TCCR0 = 0b00000001;      // 0b00000001, Vorteiler 1
  TIMSK = 0b00000001;      // 0b00000001, Timer-Overflow
}

//======================================================================


//======================================================================

SIGNAL(SIG_OVERFLOW0)            // Zeitsignal ( 1 Sekunde )
{
  i = i+1;
  if (i == 31250)
  {
    i = 0;
    Timer = Timer+1;
    if  (Timer >= 200)
    {
      Timer = 0;
    }
    Zeit_berechnen();
    Timer = Timer+1;
  }

}

//======================================================================

[Karl H. (kbuchegg)]

Chris schrieb:
> Ja Interrupt war das Stichwort .Ich hatte einen Timer interrupt drin
> .Wieso der allerdings nicht richtig ist weiß ich auch gerade nicht .

Dann lerne.

>   TIMSK = 0b00000001;      // 0b00000001, Timer-Overflow

Das, schreibst du niemals wieder so.

Sondern immer so

      TIMSK = ( 1 << TOIE0 );

Denn:
Während das Bit für den Timer Overflow beim Mega8 in der Tat das Bit 0 
ist, ist es beim Mega162 an der Bitposition 1, wie uns ein Blick ins 
m162-Datenblatt, Seite 102, verrät! Du hast nicht den Overflow Interrupt 
eingeschaltet, sondern den Output Compare Interrupt für den Timer 0 
(OCIE0). Und da du keinen Handler dafür hast, kommt der Default zum Zug, 
der .... den Prozessor resettet.

Schreibst du as Einschalten des Interrupts so wie du das geschrieben 
hast, musst du dich darum kümmern, dass das TOIE0 Bit beim m162 an einer 
anderen Stelle sitzt, als beim m8.
Schreibst du es auf die bessere Art mit Bitnamen, dann kümmert sich der 
Compiler darum.
Und im Zweifelsfall ist es immer besser, wenn sich der Compiler um etwas 
kümmert. Denn der übersieht nichts und macht auch (zumindest in der 
Beziehung) keinen Fehler. Du musst nur den Prozessor umstellen und für 
den neuen Prozessor neu compilieren und schon wird auch das richtige Bit 
gesetzt.

[g457 (Gast)]

..ich sag ja, nicht 'registerkompatibel' :-) Für amoklaufende Interrupts 
gibts übrigens extra einen BADISR_vect. Zumindest während der 
Entwicklung kann es extrem praktisch sein wenn die Kiste nicht immer 
einen Reset macht (den man mglw. nicht mal richtig mitbekommt) sondern 
gleich anzeigt^H^H^H^H^Hblinkt 'unbehandelter Interrupt' :-)

Geht aber übrigens auch noch schlimmer(tm) was die Bits angeht: Man kann 
diese nämlich zum Zwecke der Erschwerung des Protierens auch noch auf 
andere Register umverteilen, als besonderes Leckerli auch gleich noch 
auf mehrere verschiedene. Das kann dann auch der Compiler nicht mehr 
automatisch 'abfangen'. Beispielsweise liegt die Bits SM0..2 beim m8 im 
MCUCR, beim m162 dagegen sind die 3 Bits auf 3 Register verteilt: EMCUCR 
(SM0), MCUCR (SM1) und MCUCSR (SM2). Da kommt Freude auf beim µC-Wechsel 
;-)