Hintergrundwissen gefragt - Verfuste ATmega328

Und mit welchem Takt läuft der AVR?

In seiner Werkskonfiguration läuft er mit 1 MHz. Da ist alles über 250kHz auf SCK Glücksspiel.

Steht auch alles im Datenblatt.

Gruß Jobst

Robert H. schrieb:

Bei ein paar ging das nicht: Diese habe ich ausgelötet und auf eine Adapterplatine gelötet Dann habe ich diese in meinem Fusedoctor im Parallel-HV Mode ausgelesen. Und was mich hier dann gewundert hat ist, dass hier auch nur die Clockbits verstellt waren.

Auf was waren sie denn verstellt? Wenn du sie aus Versehen auf den internen 128-kHz-Oszillator gedreht hast (und dann vielleicht auch noch CKDIV8 an ist ;-), dann müsstest du schon extrem langsam mit dem SPI arbeiten, um eine Kommunikation zu ermöglichen. Da dauert dann selbst das Rücksetzen der Fuses schon locker einige Minuten.

Aber wenn ich danach nochmal per ISP die Fuses wieder auf externen Oszillator umstelle, kann ich den Controller nicht mit einem externen Takt retten, sondern nur mit dem Fusedoctor. Hat jemand von euch eine Erklärung für das Verhalten?

Wenn sie wirklich auf den externen Oszillator gedreht waren, dann wäre es in der Tat unverständlich, warum der Controller mit einem externen Takt nicht wieder „auf die Beine“ kommt.

In seiner Werkskonfiguration läuft er mit 1 MHz. Da ist alles über 250kHz auf SCK Glücksspiel

Ja, das war ja der Fehler, das in der Batchdatei der Clock des ISP zum Fuses schreiben zu hoch eingestellt war. Erst nach dem Setzen des Oszillators sollte zum Schreiben des Flash der Clock des ISP erhöht werden.

Auf was waren sie denn verstellt? Wenn du sie aus Versehen auf den internen 128-kHz-Oszillator gedreht hast

Eingestellt, sollte der interne Oszillator auf "Int. RC Osc. 8Mhz;...." werden. Aber durch den zu hohen Takt beim Flashen stand der Clock immer auf "Ext. Crystal Osc....." Dass er mal auf "Int. RC Osc. 128 kHz;" stand habe ich nie erlebt.

dann müsstest du schon extrem langsam mit dem SPI arbeiten, um eine Kommunikation zu ermöglichen.

Ich habe es auch mit langsamen Clockfrequenzen probiert. Bis runter zu ~2.1kHz. Ohne Erfolg. Das GUI ISP Tool von ATMEL Studio brachte schon nach wenigen Sekunden ein TimeOut.

Wenn sie wirklich auf den externen Oszillator gedreht waren, dann wäre es in der Tat unverständlich, warum der Controller mit einem externen Takt nicht wieder „auf die Beine“ kommt.

Das ist das was mich am meisten wundert. Ich "repariere" die ATMs mit dem Fusedoctor (auf Werkseinstellungen) und kann dann den Controller wieder mit dem MKII und dem GUI ISP Tool von ATMEL Studio ansprechen. (125kHz ISP Clock) Dann verstelle ich wirklich unter Kontrolle dieser Oberfläche auf "Ext. Crystal Osc.8.0- ..." und versuche dann mit dem Frequenzgenerator zu retten und ich schaffe es nicht. Wobei dieses Verfahren ja bei einem Großteil meiner "verfusten" Controller funktioniert hat.

Wenn ich nochmals Luft habe, dann werde ich nochmal etwas "Forensik" betreiben um auf eine Ursache zu kommen.

Allen erstmal vielen Dank Robert

Robert H. schrieb:

Ich habe es auch mit langsamen Clockfrequenzen probiert. Bis runter zu ~2.1kHz. Ohne Erfolg. Das GUI ISP Tool von ATMEL Studio brachte schon nach wenigen Sekunden ein TimeOut.

Ich denke, dass das GUI schlicht nicht darauf ausgelegt ist, so langsam zu arbeiten, und vorher "kalte Füße" bekommt.

Ich hatte das mal irgendwann mit AVRDUDE getestet und glaube, dass man dort auch mit sehr langsamem ISP-Takt arbeiten konnte, aber es dauert eben eeeeewig, denn rundherum wird ja noch ein bisschen mehr ISP-Traffic erzeugt, auf den gewartet werden muss.

Sherlock 🕵🏽‍♂️ schrieb:

Achtung: Die Änderung an diesen Fuses wird IMHO teilweise erst nach einem Power-Cycle wirksam.

Nein, nach dem Ende der aktuellen ISP-Sitzung. Einen power cycle braucht nur das Gefummel mit der DWEN-Fuse.

Jörg W. schrieb:

Wenn sie wirklich auf den externen Oszillator gedreht waren, dann wäre es in der Tat unverständlich, warum der Controller mit einem externen Takt nicht wieder „auf die Beine“ kommt.

Ich hatte mal mit Stromsparen experimentiert und einen ATtiny25 mit 32kHz Quarz und Taktteiler benutzt. Danach war ISP blockiert. Die 32kHz Fuse erlaubt max 100kHz und der Vorteiler wird wohl nur bei Power-On, aber nicht bei externem Reset zurück gesetzt. Ich kam daher nur mit HVP wieder ran. Bei kleinem Takt kann man erst auch nur die Fuses rücksetzen und muß zum Flash schreiben wieder den ISP-Takt hochsetzen.

Robert H. schrieb:

Hat jemand von euch eine Erklärung für das Verhalten?

Nein! Ich nicht.

Wenn man die Fuses per HVPP wieder auf Auslieferungszustand stellt, dann sollte auch alles wieder wie im Auslieferungszustand funktionieren, auch Fuses per ISP verstellen. Habe es nie anders erlebt, und nie anders gehört.

Also nein! Ich weiß nicht was bei dir schief läuft. Kann nur vermuten.....

Aber wie fast immer, zu wenig Information für eine tiefe Diagnose, zu wenig um zu testen. Dabei: ATmega328 habe ich sowieso nicht, nur als ATmega328P. Da kann ich sagen, die P Variante tut was es soll, wie erwartet.