ATMega 8 nach einem Beschreiben Tod

Mode Gast #346541
Lesenswert?
• ▲
▼ 
Hallo,

Ich habe meinen ATMega gerade in der Schaltung gehabt und via ISP an
com1 das erste Mai beschrieben. Hat auch wunderbar funktioniert. Nach
dem Beschreiben ist der uC nun aber zu nichts mehr zu bewegen. Das
Programm laeuft nicht und ueber ISP wird er nicht mehr gefunden.
An den Fuses habe ich nichts veraendert.

Im Quellcode steht:
#ifndef F_CPU
#define F_CPU 1000000UL
#endif


Fuer die delay Routinen. Kann es sein dass ich mir hiermit den internen
Oszillator deaktiviert habe?
Was kann ich tun um herauszufinden ob der interne Oszillator noch
schwingt?

Desweitern habe ich einen Watchdog mit den C Funktionen auf 30ms
gesetzt. Kann es sein, dass dieser mir den Aerger einbrockt? Eigentlich
nicht, da doch beim Programmieren Reset auf Low gezogen wird. ?!?

Ein anderer ATMega wird in dieser Schaltung erkannt so dass man
Hardwareprobleme ausschliessen kann.


Freue mich auf alle Tipps


Gute Nacht

Mode
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Mode Gast #346542
Lesenswert?
• ▲
▼ 
Soo mal von ext 4MHz an XTAL1 angelegt und er lebte wieder. Fusebits
waren alle nicht gesetzt. Da scheint wohl was beim Programmieren in die
Hose gegangen zu sein. Ich kann den Fehler aber nicht reproduzieren.
Kann es an einem zu langen com Kabel liegen? 5Meter....
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Wolfgang Horn Gast #346543
Lesenswert?
• ▲
▼ 
Hi, Mode,

welche Antwort erwartest Du nach Deinen Feststellungen?

"ann es an einem zu langen com Kabel liegen? 5Meter...."
Kaum. 5m Kabel wo zwischen? PonyProg? STK500?

Möglicherweise: Fusebit "CKOPT". Schau im Datenblatt mal auf S. 25,
"Table 4. Crystal Oscillator Operating Modes", da geht's um die Wahl
der Kondensatoren und die Einstellung des Arbeitspunktes mit Fusebits in
Abhängigkeit von der Quarzfrequenz.

Ciao
Wolfgang Horn
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Mode Gast #346545
Lesenswert?
• ▲
▼ 
Ja das kann gut sein, habe das Teil heute bestimmt schon 50 mal
beschrieben und es ist kein mal mehr aufgetreten... :-)

Programm ist mittlerweile fertig. und beim debuggen musst ich
feststellen das sich der interne 1MHz Osz. absolut nicht fuer UART
eignet. 2400baud war das hoechste aller Gefuehle :-(
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernhard S. #346546
Lesenswert?
• ▲
▼ 
>2400baud war das hoechste aller Gefuehle

Muss auch so sein, denn nach der Formel:

  UBRRL= TAKT/(BAUD*16)-1


sollte das Ergebnis möglichst ganzzahlig sein.


Zu hohe Fehlerabweichungen können die seriellen PC-Schnittstellen nicht
mehr kompensieren.

Aber würdest Du 2 µC mit 1Mhz und "9600Bd" (wären natürlich nicht
9600, sondern ein anderer krummer Wert)  untereinander betreiben, das
ginge dann wieder, da beide USATS mit dem gleichen Fehler laufen.

Bernhard
Antwort Zitieren Bearbeiten Löschen Beitrag melden
thkais Gast #346547
Lesenswert?
• ▲
▼ 
Bernhard: Nicht unbedingt. Der interne Oszillator ist nicht gerade das,
was man Temperaturstabil nennen könnte. Wenn man Glück hat klappts,
wenn man Pech hat, sucht man sich einen Wolf, wenn man diese
Einschränkung nicht bedenkt.
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