ATMEGA168 führt einen Reset aus

Frank L. #2309261
Lesenswert?
• ▲
▼ 
Hallo zusammen,
ich stehe hier im Moment etwas auf dem Schlauch!

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

1
/*

2
 * main.c

3
 *

4
 *  Created on: 16.08.2011

5
 *      Author: Frank

6
 */

7
#include <avr/io.h>

8
#include <util/delay.h>

9


10
void init( void )

11
{

12
  // Eingänge definieren inkl. interner Pull-Up Widerstände

13
//  DDRD  &= ~(1<<PIND6);

14
//  DDRD  &= ~(1<<PIND7);

15
//  PORTD |= (1<<PD6);

16
//  PORTD |= (1<<PD7);

17


18
  // Ausgänge definieren

19
  DDRB |= (1<<PB3);

20
  DDRB |= (1<<PB4);

21
  DDRB |= (1<<PB5);

22
  // Alles aus

23
  PORTB &= ~(1<<PB3);

24
  PORTB &= ~(1<<PB4);

25
  PORTB &= ~(1<<PB5);

26
}

27


28
int main( void )

29
{

30
  init();

31


32
  // Test auf Reset durch Programmfehler

33
  PORTB |= (1<<PB5);

34
  _delay_ms( 100 );

35
  PORTB &= ~(1<<PB5);

36


37
  while(1)

38
  {

39
    PORTB |= (1<<PB3);

40
    _delay_ms( 100 );

41
    PORTB &= ~(1<<PB3);

42
    _delay_ms( 100 );

43
  }

44
}


Ergänze ich den Code um die folgenden Zeilen:

1
/*

2
 * main.c

3
 *

4
 *  Created on: 16.08.2011

5
 *      Author: Frank

6
 */

7
#include <avr/io.h>

8
#include <util/delay.h>

9


10
void init( void )

11
{

12
  // Eingänge definieren inkl. interner Pull-Up Widerstände

13
//  DDRD  &= ~(1<<PIND6);

14
//  DDRD  &= ~(1<<PIND7);

15
//  PORTD |= (1<<PD6);

16
//  PORTD |= (1<<PD7);

17


18
  // Ausgänge definieren

19
  DDRB |= (1<<PB3);

20
  DDRB |= (1<<PB4);

21
  DDRB |= (1<<PB5);

22
  // Alles aus

23
  PORTB &= ~(1<<PB3);

24
  PORTB &= ~(1<<PB4);

25
  PORTB &= ~(1<<PB5);

26
}

27


28
int main( void )

29
{

30
  init();

31


32
  // Test auf Reset durch Programmfehler

33
  PORTB |= (1<<PB5);

34
  _delay_ms( 100 );

35
  PORTB &= ~(1<<PB5);

36


37
  while(1)

38
  {

39
    PORTB |= (1<<PB3);

40
    _delay_ms( 100 );

41
    PORTB |= (1<<PB4);

42
    _delay_ms( 100 );

43
    PORTB &= ~(1<<PB3);

44
    _delay_ms( 100 );

45
    PORTB &= ~(1<<PB4);

46
  }

47
}


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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Frank L. #2309316
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thomas E. #2309341
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thomas E. #2309385
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Frank L. #2309803
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren