Auf der Suche nach Informationen wie man verhexten Code in einem Arduino debuggen kann, ohne Myriaden von println() Statements in den Code zu streuen, habe ich mir ein Atmel-ICE zugelegt, zugegebener Maßen, ohne vorher großartig Recherchen anzustellen, mit welchen Software-Tools ich das ICE zur Zusammenarbeit mit meinem Arduino Nano V3 bewegen könnte. Im weiteren Verlauf meiner Nachforschungen bin ich dann bei Visual Micro gelandet und habe gelesen, dass „jeder Programmer unterstützt wird“, also habe ich mir die 45-Tage Trial-Version von Visual Micro sowie das aktuelle Atmel Studio V7 geladen und installiert.
Die Integration des Visual Micro Plugins in Atmel Studio funktioniert vollkommen problemlos, anschließend musste noch die aktuellste Arduino-IDE installiert und Visual Micro bekannt gemacht werden, dann konnte ich mein Programm für den Arduino ohne jegliche Änderungen am Code compilieren und mit dem Atmel-ICE über das SPI-Interface auf den Arduino laden.
Jetzt könnte ich eigentlich mit dem Debuggen beginnen, wäre da nicht noch die elektrische Verbindung zwischen Atmel-ICE und Arduino herzustellen...
Zeitsprung rückwärts…
In der Absicht, beim Kauf des Atmel-ICE ein paar Euro zu sparen, habe ich das nackte Board ohne Kabel und ohne Gehäuse gewählt.
Im Nachhinein würde ich von dieser furiosen Idee Abstand nehmen, denn die Adaption der am ICE vorhandenen 1,27 mm-Stecker auf den am Arduino Nano V3 vorhandenen 2,54 mm-Stecker ist mit Bordmitteln nur sehr schwierig zu realisieren. Alleine die Beschaffung von 0,675 mm Pitch Flachbandkabel ist hier in Deutschland Glückssache und ohne ein bekanntes Online-Kaufhaus quasi unmöglich. Doppelreihige Pfostenstecker im 1,27 mm Raster gibt es überhaupt nicht für den privaten Bastler und der von 2,54 mm Steckern gewohnte Trick, einfach zwei einreihige Pfostenreihen parallel nebeneinander zu verwenden zieht hier nicht, denn der Abstand der beiden Pfostenreihen ergibt in diesem Fall 2 mm, was natürlich nicht passt. Ich habe also die beiden einreihigen Pfostenstecker auf jeweils einer Seite mit feinem Schleifpapier soweit abgeschliffen dass der resultierende Abstand beim parallelen Anordnen auf die korrekten 1,27 mm kommt. Ein rechtes Gefummel, das ich mir, wie geschrieben, kein weiteres Mal antun möchte.
Nach Überwindung dieser Hürde konnte ich das ICE erstmals mit meinem Arduino Nano V3 verbinden.
Zurück in die Gegenwart…
Da ich bisher nicht mit dem Atmel Studio gearbeitet habe, hatte ich ein paar Anlaufschwierigkeiten auf der Suche nach den passenden Einstellungen, damit das Atmel
-ICE sowohl als Programmer über SPI als auch zum Debuggen über debugWIRE verwendet wird.
Der Arduino Nano V3, den ich für meine ersten Gehversuche beim Debuggen verwendet habe - ja, ich bin manchmal sehr vorsichtig (siehe Hinweis unten) - hat einen defekten USB-Seriell-Konverter, der normale Download des Programms per USB-Schnittstelle funktioniert also nicht. Das sollte aber kein Problem sein, denn das Atmel-ICE programmiert ja über SPI. Diese Annahme hat sich als richtig erwiesen, der Code wurde problemlos auf den µC geladen und lief.
Beim Arduino Nano und vielen anderen Arduinos ist ein Kondensator seriell zwischen DTR-Ausgang des USB-Seriell-Wandlers und dem Reset-Eingang des µC eingebaut. Dieser
Trick erlaubt die automatische Programmierung der Arduinos über USB, ohne dass man von Hand einen Reset auslösen müsste um den Bootloader zu starten.
Dieser Kondensator muss auf dem Arduino gefunden und ausgebaut werden. Möchte man das Auslöten des Kondensators vermeiden, kann alternativ die Leitung zwischen
Kondensator und dem Reset-Anschluss des µC mit einem scharfen Messer oder Skalpell vorsichtig unterbrochen werden. So hat man die Möglichkeit, diese Operation später
wieder rückgängig zu machen. Je nach Layout ist nach dem Trennen der Verbindung zum Kondensator der Reset-Taster immer noch funktional, gegebenenfalls unterschiedliche
Stellen im Verlauf der Leiterbahn zum Auftrennen in Augenschein nehmen.
Der am Reset-Eingang normalerweise vorhandene PullUp hat bei mir vorliegenden Varianten des Arduino Nano unterschiedliche Werte zwischen 1k und 10k. Letzterer bleibt unverändert, Widerstände mit kleineren Werten müssen entfernt oder gegen einen mit mindestens 10k ausgetauscht werden. Solange man mit dem Atmel-ICE arbeitet ist ein externer PullUp an Reset überflüssig, da das ICE einen internen PullUp hat. Da man aber im Allgemeinen nach dem Debuggen den Arduino wieder normal verwenden will, sollte man gleich einen passenden Widerstand einbauen, wenn man schon am Löten ist.
Jetzt der Übergang zum Debuggen. Über die Optionen im Atmel Studio wird das Atmel-ICE als Debugger ausgewählt und als Debug-Verbindung debugWIRE selektiert. Man wird darauf hingewiesen, dass man eine laufende Debug-Sitzung immer und unbedingt über die Funktion „Disable debugWIRE and Close“ beenden muss, weil sonst das SPI -Interface nicht wieder aktiviert wird und man sich somit aus dem µC ausgeschlossen hat.
Nun, irgendwie funktionierte der Rückweg bei meinem ersten Versuch im Einzelschritt durch mein Programm zu gehen nicht und der µC blieb für mich fürderhin erst mal unerreichbar. Leider verweigert die hinterlagerte Statemachine in Atmel Studio einen zweiten Versuch - der Knopf „Disable debugWIRE and Close“ wird nach der ersten Betätigung unbedienbar (grayed) und lässt sich durch nichts und niemanden dazu überreden, nochmal aktiviert zu werden.
Die vermeintlich falsch gesetzten Fuses im Arduino mittels HVPP wieder in Ordnung zu bringen ist nicht so einfach, wie es vielleicht erscheinen mag, denn man kommt nicht an alle Signale des µC heran, die man für die High Voltage Programmierung benötigt. Dass der µC im gegebenen Arduino in einem PLCC Gehäuse daher kommt, hilft genauso wenig. Alle einschlägigen Lösungen zur Rettung “ver-fuse-ter” Atmels mittels HVPP beziehen sich leider auf µC im DIP-Gehäuse, das heute kaum noch einer nutzt.
Nach längerer Recherche im Netz habe ich dann den entscheidenden Hinweis im Forum „avrfreaks.net“ entdeckt:
Bei der Installation von Atmel Studio findet auch das Befehlszeilen-Tool atprogram seinen Weg auf den Rechner und bietet uns die entscheidende Möglichkeit, den debugWIRE-Zugang des µC ohne Behinderung durch eine wildgewordene Statemachine über die Eingabe des Befehls
atprogram -t atmelice -i debugWIRE -d atmega328p dwdisable
stillzulegen und somit wieder Zugang per SPI auf den µC zu bekommen. Der oben angegebene Befehl wird im Command Fenster innerhalb der IDE eingegeben, aufgerufen über das Menü “Tools->Command Prompt”. Direkt nach Ausführung des Befehls muss über das Menü “Tools->Device Programming” die dwenable Fuse zurückgesetzt werden um SPI wieder permanent einzuschalten. Führt man an dieser Stelle einen Power cycle des Arduino durch, ist man wieder im debugWIRE-Mode und der µC bleibt über SPI unerreichbar.
Vielen Dank an dieser Stelle an Morten Olsen für den entscheidenden Tipp!
Dieser Vorgang, also per SPI die dwenable Fuse setzen, Programm durchsteppen, Fehler finden und korrigieren, übersetzen und erneuter Download per SPI, dann wieder zurück in den Debugmode, passiert während des beschriebenen Prozedere andauernd automatisch und ohne Murren und Probleme. Nur beim Abbruch der Debug-Sitzung ist mir mehrfach passiert, dass sich die dwenable Fuse nicht mehr über Atmel Studio zurücksetzen ließ und ich zum weiter oben beschriebenen Ablauf greifen muss um SPI wieder zu aktivieren.
Mein Atmel-ICE ist die PCBA-only Version. Ein Gehäuse für das Atmel-ICE wäre schön...