ATMega644 zeigt komisches Verhalten

[oderlachs]

Ein ATmega644 soll eine LED zum Leuchten...besser Blinken bringen, 2,5 sec. Dunkel und für 100 msec Hell ...das Aufblinken geht 1,2,..4 mal gut,

dann blinkt es 2..bis 3 mal kurz. hintereinader nicht aber im Abstand von 2,5 sec.

Was kann man dabei falsch machen...??

/* ========================================================================== */
/*                                                                            */
/*   Filename.c                                                               */
/*   (c) 2014 Gerhard Hinze                                                   */
/*                                                                            */
/*   MCU:   ATMega644                                                         */
/*                                                                            */
/* ========================================================================== */
#ifndef F_CPU
//#define F_CPU  3686400UL  // STK500 org
#define F_CPU   16000000UL  // STK500 ext. Qu 16Mc
#endif
#include <avr/io.h>
#include <util/delay.h>
/* ========================================================================== */
/*                                                                            */
/*                      Main Routine                                          */
/*                                                                            */
/*                                                                            */
/* ========================================================================== */

int  main(void)
{
DDRB = 0x01;
while(1)
{
PORTB |= (1<< PB0);   // = 1 : STK-LED off
_delay_ms(2500);
PORTB  &= ~(1<< PB0); // = 0 : STK-LED on
_delay_ms(100);
}
return 0;
}

Nun will ich mich nicht an dem Blinkbeispiel hochziehen, das hatte ich nur als Bsp. zum Test mit dem 644 und Headerdefinitionen geschrieben...
Da der 644 später in zeirelevanten Schaltung zur Anwendung kommen soll, macht mir das etwas Sorgen... Die Fuses habe ich kontrolliert alles OK gesetzt...
Der Q ist ein extra aufgesteckter 16MHz Quarz, der ist in Ordnung.
Wo kann bei einem solchen Verhalten die Ursache liegen ?

Gruss und Dank

Gerhard

[wkrug]

Solche komischen Sachen passieren manchmal, wenn der Watchdog aktiv ist.
Guck mal in den Fuses, ob da der Watchdog hardwaremässig aktiv ist.
Eine weiter Möglichkeit wäre, das eine Variable überschrieben wird, oder der Stack überläuft, das sollte aber bei so einer einfachen Routine eigentlich nicht passieren.

Ansonsten bleibt Dir nur die Simulation im AVR Studio.

[markusj]

Die Fuses habe ich kontrolliert alles OK gesetzt...

Kannst du die Fusebytes bitte dazu schreiben, an deinem Code fällt mir nämlich auf die schnelle nichts auf. Außer: Setzt du evtl. in deiner IDE (AVR Studio/Eclipse) auch F_CPU?

mfG
Markus

[oderlachs]

Danke erst nmal für schnelle Hinweise..
@markus die Fuses kann ich nur als Foto einfügen...

@wkrug : ich muss eingestehen, dass ich das Simulieren mit demAVR-St nicht beherrsche... mich schäme...

ich habe jetzt andere Chips getestet, ist nur mit dem ATMega 644 der komische Fehler....muss mal suchen welche Port da überhaupt für I/O so gehen...aber an den anderen Chips gehen die Ports mit selben funktionen ja ...
Ich hatte den 644 für einen Sanguino gekauft doch der braucht den 644P sonst muss ich sonst was wohl zumschreiben...Darum wollte ich den einzelnen Chip noch zu was "Anständigem" (Klimareglung) gebrauchen..

Gruss und Danke

Gerhard

[markusj]

@markus die Fuses kann ich nur als Foto einfügen...

Das sind doch nur drei oder vier Hexadezimalzahlen ...

Was das Simulieren angeht: Programmieren können ist das eine, Debugging selbst ist nochmal eine ganz andere Kunst, speziell bei Hardware-Debugging im Simulator. Von daher, kein Grund verlegen zu sein.

mfG
Markus

[oderlachs]

So ich glaube ich lege für heute mal alles was AVR ist weg.... Irgendwie hat das STK500 gesponnen, es wurde alles als OK angezeigt nur programnmiert wurde der Chip nicht... dann habe ich auf einem Protoboard(Olimex) versucht zu Proggen...ging auch nicht..
Dank der elektr. Absicherung vom STK500 ist nix geschehen..Ich hatte mit meinen "guten Augen" mal wieder schief gesehen(hab arge Probs beim 3-D Sehen) und den Chip um 1 Pin versetzt eingesteckt...
Dann kam das I-Tüpfelchen ein neu gekauftes 10pol ISP Kabel war falsch...die Farbcodierung, nach der ich mich am STK500 richten muss war auf der falschen Seite vom Stecker !! groll...

Na ja nun geht sogar der ATmega644 und hoffe das es so bleibt

Ja Brille Fielmann..wer gut sehen kann ist im Vorteil
schade ein neues Augenlicht kann man sich nicht programmieren..

Gruss

Gerhard, der wieder viel dazu gelernt hat

Nachtrag :
Habe nun den 644 und alle anderen 40-Pinner auf dem SKT 500 programmiert...alles Ok..
Ich denke dann klar, dass es am STK 500 gelegen hat, da hatten sich bestimmt ein Bytes verklemmt...hatte mal alles an Kabel abgetrennt und Jumper gezogen usw.. Nun scheint es wieder Intakt zu sein. Manchmal hilft ja nur Vtarget+ ARef zu ziehen, aber diesmal half es nicht...