ATMEGA168 führt einen Reset aus

[Frank L. (franklink)]

Hallo zusammen,
ich stehe hier im Moment etwas auf dem Schlauch!

Folgender Programmcode führt auf meinem ATMEGA168 einen Reset aus:

/*
 * main.c
 *
 *  Created on: 16.08.2011
 *      Author: Frank
 */
#include <avr/io.h>
#include <util/delay.h>

void init( void )
{
  // Eingänge definieren inkl. interner Pull-Up Widerstände
//  DDRD  &= ~(1<<PIND6);
//  DDRD  &= ~(1<<PIND7);
//  PORTD |= (1<<PD6);
//  PORTD |= (1<<PD7);

  // Ausgänge definieren
  DDRB |= (1<<PB3);
  DDRB |= (1<<PB4);
  DDRB |= (1<<PB5);
  // Alles aus
  PORTB &= ~(1<<PB3);
  PORTB &= ~(1<<PB4);
  PORTB &= ~(1<<PB5);
}

int main( void )
{
  init();

  // Test auf Reset durch Programmfehler
  PORTB |= (1<<PB5);
  _delay_ms( 100 );
  PORTB &= ~(1<<PB5);

  while(1)
  {
    PORTB |= (1<<PB3);
    _delay_ms( 100 );
    PORTB &= ~(1<<PB3);
    _delay_ms( 100 );
  }
}

Ergänze ich den Code um die folgenden Zeilen:

/*
 * main.c
 *
 *  Created on: 16.08.2011
 *      Author: Frank
 */
#include <avr/io.h>
#include <util/delay.h>

void init( void )
{
  // Eingänge definieren inkl. interner Pull-Up Widerstände
//  DDRD  &= ~(1<<PIND6);
//  DDRD  &= ~(1<<PIND7);
//  PORTD |= (1<<PD6);
//  PORTD |= (1<<PD7);

  // Ausgänge definieren
  DDRB |= (1<<PB3);
  DDRB |= (1<<PB4);
  DDRB |= (1<<PB5);
  // Alles aus
  PORTB &= ~(1<<PB3);
  PORTB &= ~(1<<PB4);
  PORTB &= ~(1<<PB5);
}

int main( void )
{
  init();

  // Test auf Reset durch Programmfehler
  PORTB |= (1<<PB5);
  _delay_ms( 100 );
  PORTB &= ~(1<<PB5);

  while(1)
  {
    PORTB |= (1<<PB3);
    _delay_ms( 100 );
    PORTB |= (1<<PB4);
    _delay_ms( 100 );
    PORTB &= ~(1<<PB3);
    _delay_ms( 100 );
    PORTB &= ~(1<<PB4);
  }
}

ist alles in Ordnung.

Ursprünglich wollte ich eigentlich nur IRMP und debounce über Interrupt 
zusammenbringen. Dabei bin ich auf dieses merkwürde Verhalten gestossen.

Auf einem ATMEGA8 ist alles ok. Nur hat der leider zu wenig Speicher für 
mein Vorhaben.

Entwicklungsumgebung: Eclipse mit AVR-Toolchain und WinAvr20100110

Gruß
Frank

[Helfer (Gast)]

Was ist an PB3, PB4 und PB5 angeschlossen? Wieviel Strom zieht dein AVR? 
Geht der AVR in den Brownout?

[Frank L. (franklink)]

Hallo,
an den Pins sind nur einfache kleine LEDs angeschlossen. Ich glaube, 
dass kann man auch ausschliessen, da Brown-Out disabled ist.

Tatsächlich ist es so, dass wenn nur eine LED (PB5) - die Resetprüfung - 
im Code geschaltet wird, das Teil einen Reset ausführt.

Wird zusätzlich noch die LED an PB3 geschaltet, das gleich Resultat, 
kommt die LED an PB4 hinzu ist alles ok.

In jedem Fall sehr merkwürdig.

Gruß
Frank

[Karl H. (kbuchegg)]

Frank Link schrieb:
> Hallo,
> an den Pins sind nur einfache kleine LEDs angeschlossen. Ich glaube,
> dass kann man auch ausschliessen, da Brown-Out disabled ist.

Immer langsam mit den jungen Pferden.
Die LED: hoffentlich mit Vorwiderstand.

[Thomas E. (thomase)]

Frank Link schrieb:
> Tatsächlich ist es so, dass wenn nur eine LED (PB5) - die Resetprüfung -
> im Code geschaltet wird, das Teil einen Reset ausführt.
> Wird zusätzlich noch die LED an PB3 geschaltet, das gleich Resultat,
> kommt die LED an PB4 hinzu ist alles ok.

Dann schalte mal PB4 auf Eingang.
Wenn es dann funktioniert hast du eine Verbindung zwischen PB5 und PB4, 
mit der der Controller nicht sofort, sondern nach kurzer Zeit wegen 
Überstrom resettet, sprich einfach zusammenbricht.

Schaltest du in der Zwischenzeit beide auf den gleichen Pegel, 
funktioniert es.

mfg.

[Frank L. (franklink)]

Sorry,
es fehlt eine wichtige Info, da können wir alles Hardwareprobleme direkt 
ad acta legen.

Der 168er steckt in einem MyAvrMk II Board und das Board ist technisch 
i.o., da der Programmcode mit einem ATMega8 und gleichem Board 
funktioniert.

Gruß
Frank

[Thomas E. (thomase)]

Frank Link schrieb:
> Der 168er steckt in einem MyAvrMk II Board und das Board ist technisch
> i.o., da der Programmcode mit einem ATMega8 und gleichem Board
> funktioniert.

Dann schmeiss' den 168er in den Müll. Dann ist der kaputt. Kann ich mir 
aber kaum vorstellen, der Controller ist meistens unschuldig.

Schalte trotzdem mal PB4 auf Eingang und guck', was dann passiert.


Frank Link schrieb:
> da können wir alles Hardwareprobleme direkt ad acta legen.

Das hab' ich auch schon oft gedacht.

mfg.

[Frank L. (franklink)]

Hallo Zusammen,
so ich hatte jetzt nochmal etwas Zeit mir das Spiel anzusehen. Fazit, es 
kann nur der Controller sein, sso merkwürdig wie der sich verhält, kann 
es nichts anderes sein.

Sobald ich das delay nach dem Init und vor der while-Schleife entferne 
läuft das Teil. Mache ich aber einen Hardware-Reset, läuft das Programm 
nicht mehr an. Lade ich das Programm wieder hoch startet es wieder...

Das ganze nochmals auf Mega8 umkompiliert, Mega8 eingebaut und läuft.

Also, morgen einen neuen Mega168 holen und nochmal testen...

Gruß
Frank