Announcement: there is an English version of this forum on Hallo zusammen, ich habe ein kleines Problem bei dem euer Expertenwissen gefragt ist: Durch einen Fehler in einem Batchscript habe ich ein paar ATMega 328 "verfused". Im Batchscript setzte ich zuerst die Fuses mit einer niedrigeren Geschwindigkeit (125kHz) Dann verlasse ich STK500.exe und schreibe das Flash mit 500kHz. Das klappt bei allen Projekten ohne Probleme. In einer Batchdatei hatte ich einen Fehler und habe die Fuses mit 250kHz geschrieben. Bei 35 von 50 Controllern ging das gut. Bei den anderen wurde der Schritt mit einem Fehler beim Verify der Fuses beendet. Was passiert ist, ist das die Fuses auf externen Click gesetzt wurden! Ein Großteil der Controller könnte ich mit externen Takt (Frequenzgenerator 125kHz Sqrt 5Vpp 2.5V DC Offset) wieder ansprechen und die Fuses zurücksetzen auf "intern RC". 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. Nach dem Zurücksetzen der Fuses auf Auslieferungszustand ließ der Mega auch wieder per ISP mit einem MKII Clone ansprechen. 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? Kann beim Übertakten beim Setzen der Oszillatorbits im Controller was kaputt gegangen sein? Warum ich noch STK500.exe verwende? - Es muss unter Windows laufen - weil an dem Arbeitsplatz auch andere Arbeiten durchgeführt werden - Es ist das einzige Tool das ICH BISHER gefunden habe, das sich in 4 Instanzen starten lässt. (#) - es sollte zur Zeit der in Dienststellung fast nichts kosten. - damals Firmenphilosophie, die sich halt irgendwann mal rächt (#) Beim verwendeten MKII Clone lässt ich die Seriennummer ändern. Dann kann ich die Batchdatei mit vier verschiedenen Seriennummern starten. Epilog: Ich hatte das selbe Problem schon mal bei jemandem anders. Dort wurde monatelang ATM328 im TQFP-32 zu schnell geflashed (Fuses) – ohne Probleme. Plötzlich gab es Probleme die auf zu schnellen Clock beim Fuse setzten zurückzuführen waren. Damals konnte ich von 10 Controllern 9 mit externen Takt retten und einen mit dem Fusedoctor. Bei dem hat sich SPI ausgeschaltet. Danach funktionierte dieser im Gegensatz zum oben beschrieben Effekt ohne Probleme.
:
Bearbeitet durch Moderator
Beitrag #7781820 wurde von einem Moderator gelöscht.
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
:
Bearbeitet durch User
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.
Robert H. schrieb: > Erst nach dem Setzen des > Oszillators sollte zum Schreiben des Flash der Clock des ISP erhöht > werden. Achtung: Die Änderung an diesen Fuses wird IMHO teilweise erst nach einem Power-Cycle wirksam.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.