Vor drei Jahren habe ich einen kurzen Blogbeitrag über AVR-Fuses geschrieben und darüber, was zu tun ist, wenn du deine MCU durch das Setzen der falschen Fuse unkommunikativ gemacht hast. Dazu gehörten eine Menge Jumper-Drähte. Um diese loszuwerden, habe ich vor kurzem beschlossen, ein Arduino-Shield zu entwickeln, das die Wiederherstellung „toter“ MCUs unterstützt und das man jetzt bei Tindie kaufen kann.

I sell on Tindie

Der erste Impuls, um ein solches Shield zu entwerfen und die Firmware zu überarbeiten, kam, als ich die Frage eines Nutzers erhielt, wie man einen ATtiny2313 für die High-Voltage(HV)-Programmierung mit meinem RescueAVR-Sketch verdrahtet. Ich dachte, dass diese Frage leicht zu beantworten sei. Es stellte sich jedoch heraus, dass ich mich erst einmal intensiv am Kopf kratzen musste, bevor ich antworten konnte. Der Grund dafür ist, dass bei den ATtinys zwei Steuerleitungen verbunden sind, und es ist nicht sofort klar, wie sich das auf die Verdrahtung des Chips auswirkt. Ein Blick in den Code zeigt, dass die XA1/BS2-Leitung auf der UNO-Seite von dem Pin gesteuert wird, der normalerweise für die BS2-Leitung verwendet wird.

Nachdem ich mir den Code und die Dokumentation angeschaut hatte, die ich vor mehr als zehn Jahren geschrieben hatte, begann ich Fragen zu stellen, wie zum Beispiel:

  • Woher stammen die Daten über die MCUs?
  • Sind diese Daten korrekt?
  • Funktioniert der Sketch wirklich auf allen Chips?
  • Auch auf veralteten, wie dem AT90S2323?
  • Gibt es Chips, die nicht von dem Sketch behandelt werden?
  • Und könnten wir die Verdrahtung nicht irgendwie einfacher machen?

Lass uns mit Antworten auf die letzte Frage beginnen. Als erstes habe ich in Anhang B des Manuals Verdrahtungspläne für alle DIP/SOIC-Chips bereitgestellt. Allerdings muss man immer noch 20 Jumper-Drähte und ein paar andere Komponenten in das Breadboard stecken. Außerdem braucht man eine externe 12-V-Quelle, um die HV-Programmierung durchzuführen. Also habe ich mir überlegt, ein Arduino-UNO-Shield zu entwerfen, das bereits eine 12-V-Quelle an Bord hat, einen elektronischen Schalter besitzt, um diese Spannung an die RESET-Leitung anzulegen, und einen Sockel mit aufgedruckten Bezeichnungen für alle Jumper-Drähte bereit stellt. Da passen dann allerdings auch noch ein paar IC-Sockel auf das Arduino-Shield, so dass die Verkabelung nur für SMD-Bauteile benötigt wird. Dann habe ich auch noch eine Adapterplatine entworfen, weil ich nicht alle IC-Sockel auf einem Shield unterbringen konnte.

Das Resultat sieht ähnlich aus wie das HV Rescue Shield 2 von MightyOhm, aber es kann alle klassischen AVR-Chips mit DIP-Footprint verarbeiten und die Firmware ist etwas leistungsfähiger und universeller. Die Designdaten zu dem Arduino-Shield und der Adapterplatine findet man im RescueAVR-Repository. Außerdem kann man die Platinen und einen günstigen Bausatz, der ziemlich einfach zusammen zu bauen ist, bei Tindie kaufen.

Da die Sache mit den Jumper-Drähtem nun geklärt ist, wie sieht es mit den anderen Fragen aus? Ich muss gestehen, dass ich nicht mehr weiß, wie die große Tabelle mit den MCU-Daten und Standardwerten für die Fuse-Bits entstanden ist. Ich glaube, ich habe mit der Liste der MCUs auf dem Siebdruck meines Fusebit Doctor Boards angefangen. Die Signaturen stammten aus den Datenblättern, und die Standard-Fuse-Werte wurden aus dem Engbedded AVR Fuse Calculator kopiert, was die falschen Werte für die AT90S*-Typen erklären würde.

Also beschloss ich, dass es endlich an der Zeit war, alle MCUs einzubeziehen, die mit HV-Programmierung programmiert werden können. Mit einem Python-Skript, das du im RescueAVR-Github-Repository findest, habe ich die Daten für alle MCUs, die derzeit von der Microchip-Software unterstützt werden, aus den ATDF-Dateien extrahiert. Außerdem habe ich veraltete Chips einbezogen, die bereits in früheren Versionen des Sketches behandelt wurden. Für diese habe ich die Datenblätter konsultiert. Alles in allem kann der RescueAVR-Sketch jetzt mit 131 verschiedenen MCUs umgehen (und ich habe die A- und V-Versionen, die die gleiche Signatur wie die Chips ohne diesen Suffix haben, nicht mitgezählt).

Das sind zwar tolle Neuigkeiten, aber es bleibt die Frage, ob RescueAVR das Richtige tut, wenn es mit einer ungetesten MCU konfrontiert wird. Glücklicherweise habe ich viele verschiedene AVR MCUs gesammelt, die ich zum Testen meines Hardware-Debuggers verwendet habe. Trotzdem fehlten noch ein paar, die ich bei verschiedenen Quellen bestellt habe, darunter auch bei chinesischen Anbietern, da ich in Europa keine Quelle finden konnte.

Als ich RescueAVR mit diesen Chips testete, entdeckte ich tatsächlich ein paar Fehler und Probleme. Die alten Chips mit dem Präfix AT90S gehen mit den Fuse- und Lock-Bits auf eine komische Art und Weise um, die mit den neueren Chips nicht kompatibel ist. Fuse- und Lock-Bits werden mit einer Operation gelesen, wobei die zwei Lock-Bits als die beiden höstwertigsten Bits zurück gegeben werden. Schreiben der Bits erfolgt mit zwei verschiedenen Operationen. Außerdem haben einige Chips dieser Serie ein anderes Timing. Während die modernen Atmega und Attiny 120 ns für den Schreibimpuls benötigen, erwarten die AT90S-Chips mindestens 5 ms für die Erase-Operation und mindesten 1 ms für das Schreiben von Fuse-Bytes. Schließlich muss man bei den AT90S2313 und AT90S8515, die ich erhalten habe, das Lock-Byte zweimal hintereinander schreiben, damit das Setzen der Lock-Bits erfolgreich ist.

Dann stellte ich noch fest, dass der ATtiny12 das Ändern der Fuse-Bits erlaubt, selbst wenn das Lock-Bit LB1 programmiert ist, entgegen den Angaben im Datenblatt. Zuerst dachte ich, dass ich einen fehlerhaften Chip habe, aber das passierte auch mit einem zweiten Chip . Außerdem geben der ATtiny11 und ATtiny12 manchmal ein Null-Bit für unbenutzte Bits in den Fuse- und Lock-Bytes zurück, ein Verhalten, das diese Chips von allen anderen MCUs der AVR-Familie unterscheidet. Alle anderen Chips (vor allem die veralteten) funktionierten jedoch problemlos, mit einer Ausnahme.

Die Ausnahme ist der ATtiny15, ein sehr veralteter MCU-Typ, der keinen RAM-Speicher besitzt. Es scheint die einzige 8-polige AVR-MCU zu sein, bei der die Funktionalität der Pins 2 und 3 vertauscht ist. Da bei der HV-Programmierung nur entweder Pin 2 oder Pin 3 als Clock-Pin verwendet wird, sollte ein Kurzschluss zwischen den beiden Pins ausreichen, um eine Programmierbarkeit aller 8-poligen MCUs zu ermöglichen. Leider funktioniert das für den ATTiny15 nicht. Schlimmer noch, selbst wenn ich nur Pin 3 benutzte, funktionierte es nicht. Nach intensivem Studium des Datenblatts wurde dann klar, dass beim ATtiny15 der externe Takt sechzehnmal höher sein muss als der interne Takt (im Gegensatz zu allen anderen AVR-MCUs). Aus diesem Grund gibt es jetzt einen weiteren HV-Programmiermodus („HVSP for Tiny15“), so dass man jetzt auch den ATtiny15 programmieren kann. Man benötigt dafür aber ein Breadboard und Jumper-Kabel wegen des oben erwähnten Pin 2/Pin 3-Problems.

Nachdem ich den Sketch mit einer viel größeren Anzahl von MCUs als vor zehn Jahren getestet habe, ist der RescueAVR-Sketch jetzt in viel besserer Verfassung. Mit den Verdrahtungsplänen im Anhang B des Manuals sollte es ein Kinderspiel sein, eine Breadboard-Schaltung zur HV-Programmierung für jeden AVR-Chip zu erstellen. Und mit meinem neu erstellten Arduino-Shield ist es sogar noch einfacher.

Ändern der Fusebits bei einer AT90S8535 MCU

Zum Schluss noch drei wichtige Hinweise. Erstens: Man sollte immer zuerst den Sketch hochladen bevor man die Jumperkabel setzt oder das RescueAVR Shield auf den UNO steckt. Ansonsten könnten Ausgänge, die einen hohen Pegel haben, mit GND kurzgeschlossen werden.

Zweitens: Wenn man das HV-Pogrammiergerät verwendet, sollte man sicher stellen, dass alles richtig verdrahtet ist oder dass der Chip in der richtigen Fassung und mit der richtigen Ausrichtung sitzt. Andernfalls kann es passieren, dass der Chip, der wiederhergestellt werden soll, zerstört wird, weil 12 V an einen MCU-Pin angelegt werden, der nicht der RESET-Pin ist.

Zweitens scheinen die Standard-Fuse-Werte, die aus den ATDF-Dateien abgeleitet wurden, nicht immer mit den Angaben in den Datenblättern übereinzustimmen. Sie scheinen aber immer „sicher“ zu sein. Das heißt, man kann nach Rücksetzen der Fuses auf die Standardwerte einen ISP-Programmierer verwenden.

EDIT: Post um Erfahrung mit AT90S Chips und ATtiny15 sowie um eine weitere Warnung ergänzt.

Views: 37