Programmablauf startet nicht

Lars Gast #2815073
Lesenswert?
• ▲
▼ 
Hallo, ich habe bei meinem Atmega16 gerade ein recht seltsames Problem. 
Das überspielen meines Testprogramms funktioniert noch, allerdings 
beginnt der µC danach nicht wie gewohnt mit der Programmabarbeitung.
Da ich in diesem Projekt, das erste Mal mit einem Schwingquarz (16 MHz) 
hantiere, wäre es auch denkbar, dass das Fehlverhalten durch falsch 
eingestellte Fusebits kommt.
Bei der Einstellung der Fusebits habe ich zusätzlich zum 
voreingestellten Auslieferungszustand das CKOPT Bit aktiviert und beim 
SUT_CKSEL
Ext. Clock; Start-up Time: 6 CK + 64 ms eingestelt. Sind diese 
Einstellungen korrekt?
Den Quarz habe ich in der ganz normalen Standardschaltung an XTAL1 und 
XTAL2 mit zwei 22pF Folienkondensatoren zur Masse angeschlossen.

Um dem Problem auf den Grund zu gehen habe ich auch probiert das ganze 
Programm über die JTAG-Schnittstelle meines AVR-Dragons zu debuggen. 
Auch hier zeigt der Atmega ein recht seltsames Verhalten. Wenn ich auf 
Start Debugging drücke, tut sich erst mal gar nix (kein gelber Pfeil), 
außer dass der Cursor am Programmbeginn blinkt, das Debugging startet 
also nicht wirklich.

Wenn ich dann versuche das Debuggen durch Drücken auf Reset und Break 
anzuhalten, erscheint auf einmal der gelbe Debugpfeil, allerdings 
erscheint er nicht am Anfang von Main, sondern am Programmende. Unten im 
Message-Fenster wird außerdem angezeigt, dass der µC in den Sleep-Mode 
gegangen ist. Wenn ich danach auf Run drücke wird die Sleep-Mode Meldung 
im Message-Fenster wiederholt ausgegeben.

Zur Vervollständigkeit halber hier noch mein kurzes Testprogramm:

1
#include <avr/io.h>

2
#include "lcd-routines.h"

3
#include <util/delay.h>

4
#include <stdlib.h>

5
#include <stdio.h>

6


7
delay_ms(uint16_t ms)

8
{

9
  while(ms>0)

10
  {

11
    _delay_ms(1);

12
    ms--;

13
  }

14
}

15


16
char buffer[20];  

17
uint8_t zahl=30;

18
double dezimalzahl= 5.32;

19


20


21
int main(void)

22
{

23
  // Initialisierung des LCD

24
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken

25
  // verschwunden sein

26
  lcd_init();

27
  DDRD= 0b10000000;

28
 

29
  

30
  // Die Ausgabemarke in die 2te Zeile setzen

31
  lcd_setcursor( 0, 1 );

32
 

33
  // erneut Text ausgeben, aber diesmal komfortabler als String

34
  lcd_string("Hello");

35


36
  while(1)

37
  {

38
  PORTD= 0b10000000;

39
  }

40
 

41
  return 0;

42
}


Vielen Dank schon mal im Voraus für eure Mühen mir zu Helfen.

Gruß
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Karl H. #2815111
Lesenswert?
• ▲
▼ 
Lars schrieb:
> Hallo, ich habe bei meinem Atmega16 gerade ein recht seltsames Problem.
> Das überspielen meines Testprogramms funktioniert noch, allerdings
> beginnt der µC danach nicht wie gewohnt mit der Programmabarbeitung.
> Da ich in diesem Projekt, das erste Mal mit einem Schwingquarz (16 MHz)
> hantiere, wäre es auch denkbar, dass das Fehlverhalten durch falsch
> eingestellte Fusebits kommt.

Da gibt es eigentlich nur 2 Möglichkeiten
Entweder der Quarz ist aktiv oder er ist nicht aktiv, weil du falsch 
gefused hast.

Da würde ich doch mal ein noch einfacheres Testprogramm vorschlagen. 
Denn bei deinem muss schon allerhand korrekt funktionieren, damit du am 
LCD eine Ausgabe siehst.

Das allereinfachste Testprogramm ist eine LED mit _delay_ms blinken 
lassen.

1
#define F_CPU 16000000

2
#include <avr/io.h>

3
#include <util/delay.h>

4


5
#define LED_DDR  DDRD

6
#define LED_PORT PORTD

7
#define LED_PIN  PD7

8


9
int main()

10
{

11
  LED_DDR |= ( 1 << LED_PIN );

12


13
  while( 1 ) {

14
    LED_PORT |= ( 1 << LED_PIN );

15
    _delay_ms( 1000 );

16
    LED_PORT &= ~( 1 << LED_PIN );

17
    _delay_ms( 1000 );

18
  }

19
}


Mit diesem Programm (die LED Werte bei den #define einsetzen), muss 
deine LED im 1 Sekundentakt an und aus gehen. Tut sie das, ist alles in 
Ordnung. Dein QUarz ist per Fuse aktiv und versorgt den µC auch mit 
Takten.

Ist die LED aber 16 Sekunden an/aus (also gegebenenfalls etwas warten), 
dann läuft der µC immer noch mit 1Mhz.

Tut sich 1 Minute überhaupt nichts an der LED, dann hast du höchst 
wahrscheinlich deinen µC verfust und musst sehen, dass du ihn mit einem 
externen Takt wieder zur Kooperation überredest.

Blinkt deine LED allerdings richtig und tut sich danach immer noch 
nichts am LCD, dann wird wohl im LCD Code irgendein Problem vorliegen. 
Meistens sind das irgendwelche Timingsachen, so dass das LCD zeitlich 
überfahren wird.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lars Gast #2815127
Lesenswert?
• ▲
▼ 
Oliver J. schrieb:
> Dann wird der µC auch mit einem Takt versorgt. Hast du eventuell die
> Brown-out-Detection aktiviert?
>
>
> Gruß Oliver

Die Brown-out-Detection habe ich auf 2,7V eingestellt

Kan asta schrieb:
> Betrachte RESET.

Den Reset Pin habe ich ganz normal über einen 10k Widerstand an Vcc 
angeschlossen. Habe gerade nochmal nachgemessen. Bei eingeschalteter 
Betriebsspannung liegen am RESET-Pin ganz normal 5V an.


Die Betriebsfrequenz von 16 MHz habe ich nur bei der Generierung des 
Makefiles eingestellt. Ist das ausreichend oder muss ich die woanders, 
z.B. im Kommunikationsfenster zwischen Dragon und Atmega, auch noch 
einstellen?

Gruß
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lars Gast #2815169
Lesenswert?
• ▲
▼ 
Karl Heinz Buchegger schrieb:
> Da gibt es eigentlich nur 2 Möglichkeiten
> Entweder der Quarz ist aktiv oder er ist nicht aktiv, weil du falsch
> gefused hast.
>
> Da würde ich doch mal ein noch einfacheres Testprogramm vorschlagen.
> Denn bei deinem muss schon allerhand korrekt funktionieren, damit du am
> LCD eine Ausgabe siehst.
>
> Das allereinfachste Testprogramm ist eine LED mit _delay_ms blinken
> lassen.

Das ganze habe ich jetzt probiert mit diesem Testprogramm:

1
#include <avr/io.h>

2
#include "lcd-routines.h"

3
#include <util/delay.h>

4
#include <stdlib.h>

5
#include <stdio.h>

6


7


8


9


10
int main(void)

11
{

12
 

13
 DDRD= 0b10000000;

14


15
  while(1)

16
  {

17
  PORTD= 0b10000000;

18
  _delay_ms(1000);

19
  PORTD= 0x00;

20
  _delay_ms(1000);

21
  }

22
 

23
  return 0;

24
}


Die Spannung an PD7 habe ich mit dem Oszi überwacht. Leider ist die 
Spannung immer auf 0 Volt. Deswegen schaut es wohl so aus als ob ich den 
Atmega verfust habe. Was würdet ihr mir dann jetzt vorschlagen wie ich 
den AVR wiederbeleben kann?

Das Verfusen muss wohl daher kommen, dass ich zuerst bei den Fuses für 
SUT_CKSEL zuerst ext. Crystal/Resonator High Freq.; start-up time: 16K 
CK + 64ms und anschließend noch die Standardeinstellung mit dem internen 
Clock 1MHz ausprobiert habe, bevor ich dann schließlich meine jetzige 
Fuse-Einstellung gemacht habe.

Gruß
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lars Gast #2815244
Lesenswert?
• ▲
▼ 
So jetzt gehts. Hat sich erledigt. Dachte mir irgendwie gleich dass der 
Atmega nicht verfust ist, weil ich ja immer noch über JTAG die Fuses 
verändern konnte.
Auf dieser Seite
http://www.mikrocontroller.net/articles/AVR_Fuses#Reaktivieren_bei_fehlerhaften_Taktquellen-Fuse-Einstellungen

habe ich gerade gelesen, dass man wenn man einen Schwingquarz als 
Taktquelle hat in den Fuses External Crystal/Ceramic Resonator 
einstellen muss. Nach dem ich meine Fuseeinstellung jetzt auf darauf 
eingestellt habe erkenne ich auf dem Oszilloskop ein schönes Signal mit 
0,5 Hz Frequenz. Auch meine JTAG-Debugging funktioniert nun problemlos.

Was mich nur ein wenig wundert ist, dass niemand hier aufgefallen ist, 
dass ich die Fuses falsch eingestellt habe. Dachten wohl alle ich habe 
keinen Quarz sondern einen Quarzoszillator.

Gruß
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