Hast du dich schon mal gefragt, ob du den AVR-Debugger, den du in Opas Ersatzteilkiste gefunden hast, für dein neuestes Hardware-Projekt nutzen kannst? Hier kommt die umfassende Liste der AVR-Debugger, die genau solche Fragen beantwortet.
Terminologie
Zuerst fragst du dich vielleicht, ob es Unterschiede zwischen Debug-Sonden, Debug-Adaptern, Debuggern und ICEs (In-Circuit Emulatoren) gibt. Die kurze Antwort: Heutzutage werden diese Begriffe meist synonym verwendet.
Historisch gesehen waren In-Circuit-Emulatoren komplexe elektronische Geräte, die einen echten Mikrocontroller ersetzt haben. Sie haben das Verhalten der MCU emuliert und gleichzeitig ermöglicht, die internen Abläufe der MCU zu untersuchen. Atmel hat zum Beispiel in den 90ern einen solchen ICE namens AVR ATmegaICE verkauft – für rund 4000 US-Dollar.
Mit der Zeit wurde es möglich, Debug-Hardware direkt in die Chips zu integrieren. Dadurch entstand das sogenannte On-Chip-Debugging (OCD). In diesem Fall muss der Mikrocontroller nicht mehr ersetzt werden, sondern man braucht nur ein paar freie Pins, um mit dem OCD-Modul auf dem Chip zu kommunizieren. Als Schnittstelle wird häufig JTAG verwendet. Im Jahr 2001 brachte AVR seinen ersten Debugger auf den Markt, den AVR JTAG ICE. In dessen Handbuch wird erklärt:
… how On-chip Debugging differs from other In-circuit Emulator (ICE).
On-Chip-Debugging wurde also als eine weitere Form der In-Circuit-Emulation gesehen – obwohl eigentlich nichts mehr emuliert wird. Der Code läuft vollständig auf dem Chip selbst. Trotzdem haben Atmel und später Microchip ihre Debugger weiterhin ICEs genannt.
Im ARM-Umfeld heißen diese Geräte meist Debug-Adapter oder Debug-Sonden. Im Grunde ist aber immer dasselbe gemeint: ein Stück Hardware, das die Verbindung zwischen MCU und dem Host herstellt, auf dem die Debug-Software läuft, zum Beispiel der GDB-Debugger. In diesem Text verwenden wir durchgehend den Begriff Debugger.
Proprietäre Atmel-/Microchip-Debugger
Die folgende Tabelle gibt einen Überblick über alle AVR-Debugger, die zunächst von Atmel und später von Microchip vermarktet wurden.
| Name | Launched | Obsolete | EDBG protocol | AVaRICE support | Studio 7 support | MPLAB X support | Supported interfaces |
|---|---|---|---|---|---|---|---|
| AVR JTAG ICE | 2001 | Yes | No | Yes | No | No | only JTAG |
| AVR JTAGICE mkII | 2004 | Yes | No | Yes | Yes | No | all but UPDI |
| AVR Dragon | 2006 | Yes | No | Yes | Yes | No | all but UPDI |
| AVR ONE! | 2008 | Yes | No | No | Yes | No | all but UPDI |
| AVR JTAGICE3 | 2011 | Yes | Yes | Yes | Yes | No | all |
| Atmel-ICE | 2014 | No | Yes | Yes | Yes | Yes | all |
| Atmel Power Debugger | 2017 | No | Yes | Yes | Yes | Yes | all |
| MPLAB PICkit 4 ICE | 2018 | No | Yes | Yes | Yes | Yes | all |
| MPLAB SNAP | 2018 | No | Yes | Yes | Yes | Yes | all |
| MPLAB PICkit 5 ICE | 2023 | No | No | No | No | Yes | all |
| MPLAB 5 ICD | 2023 | No | No | No | No | Yes | all |
| MPLAB PICkit Basic ICE | 2025 | No | No | No | No | Yes | all |
Die Spalte EDBG protocol ist gleichbedeutend mit der Unterstützung durch die GDB-Server Bloom und PyAvrOCD.
Während die meisten älteren Debugger noch von Microchip Studio 7 und dem Open-Source-Tool AVaRICE unterstützt werden, fehlt bei vielen die Unterstützung für das neuere UPDI-Debug-Interface. Der AVR ONE!, eines der teureren Tools (über 600 €), hat offenbar nie Unterstützung in AVaRICE erhalten. Zumindest konnte ich dafür weder im Quellcode noch in der Dokumentation Hinweise finden. Wahrscheinlich hat sich einfach kein Open-Source-Enthusiast gefunden, der so ein Teil gekauft hat.
Außerdem ist der allererste Debugger, der AVR JTAG ICE, hinsichtlich der unterstützten Chips stark eingeschränkt. In der AVaRICE-Manpage werden nur folgende genannt: AT90CAN128, ATmega128, ATmega16, ATmega162, ATmega169, ATmega32, ATmega323 und ATmega64.
Zum Schluss sollte man noch die Hardware-Debugger erwähnen, die direkt auf Entwicklungsboards integriert sind, zum Beispiel auf ATmega328P Xplained Mini Boards. Hier ist der Debugger Teil des Boards, und man muss sich weder um die Verkabelung noch um die richtigen Fuse-Einstellungen kümmern.
Open-Source-Debugger und Klone
Natürlich haben Leute auch versucht, günstigere Alternativen zu den originalen Debuggern zu entwickeln oder Lösungen zu schaffen, die nicht an die proprietären IDEs von Atmel und Microchip gebunden sind. Neben Open-Source-Software, die mit den originalen Debuggern arbeitet, gab es auch Versuche, eigene Debugger zu entwerfen und zu bauen.
Zu Beginn hat Atmel alle Informationen zum JTAG-Protokoll veröffentlicht, was es ermöglicht hat, JTAG ICE und JTAGICE mkII als Klone nachzubauen. Einen JTAG-ICE-Klon von Olimex bekommt man heute noch für unter 20 €. Auch JTAGICE-mkII-Klone waren früher sehr verbreitet. Seit es aber den MPLAB SNAP für unter 10 € gibt, sind solche Klone kaum noch interessant.
Die debugWIRE- und UPDI-Protokolle, die jeweils nur eine Leitung verwenden, wurden reverse-engineered, was zu einigen Open-Source-Lösungen geführt hat. In beiden Fällen handelt es sich im Prinzip um ein asynchrones, halbduplexes serielles Protokoll, und die Kommunikation ist nicht verschlüsselt. Deshalb ist es relativ einfach, den Datenverkehr mitzuschneiden und zu interpretieren.
Der erste bekannte Versuch stammt von RiskusW und führte zu einer groben Dokumentation unter
http://www.ruemohr.org/docs/debugwire.html (heute nur noch über die Wayback Machine erreichbar). Darauf aufbauend entstanden mehrere Open-Source-Projekte mit einfacher symbolischer Debug-Unterstützung oder sogar GDB-Servern. Am bekanntesten ist vermutlich dwire-debug. Hier besteht der Debugger im Wesentlichen aus einer USB-UART-Bridge mit einer zusätzlichen Schottky-Diode, wie im folgenden Bild gezeigt.
dwire-debugger Hardware (Photo von David C W Brown aus dem GitHub repo)
Die gesamte „Intelligenz“ steckt dabei im Host-Programm, das die USB-UART-Bridge steuert. Basierend auf dewire-debug gab es weitere Projekte, die als Debugger-Hardware auch jeweils nur eine USB-UART-Bridge eingesetzt haben.
Ein alternativer Ansatz war DebugWireDebuggerProgrammer, bei dem mehr Verarbeitung in die Debugger-Hardware gesteckt wurde. Als Weiterentwciklung kann dw-link angesehen werden. Das ist eine Firmware für den Arduino UNO, die direkt einen GDB-Server auf dem UNO implementiert. Man kann GDB also direkt über die serielle Schnittstelle mit dem Arduino verbinden.
UNO als dw-link-Debugger (Eigenes Photo)
Wie erwähnt wurde auch UPDI (zumindest teilweise) reverse-engineered. Auch hier ist der Debugger eine USB-UART-Bridge, diesmal gesteuert von einem Scheme-Programm namens updi-gdbserver.
All diese Ansätze sind spannend und technisch interessant, haben aber gewisse Schwächen, zum Beispiel beim Thema Pegelanpassung. In diesem Zusammenhang ist ein anderes Projekt besonders erwähnenswert: der microUPDI-Debugger. Dabei handelt es sich um einen Arduino Pro Micro, der mit der offiziell verfügbaren Firmware der mEDBG-Debugger geflasht wird, ergänzt um Pegelwandler- und Puffer-Schaltungen. Außerdem versorgt dieser Debugger, im Gegensatz zu seinen kommerziellen Cousins, das Target-Board auch mit Strom. Das gesamte Hardware-Design ist Open Source.
/i/75454/products/2019-08-28T17%3A42%3A42.970Z-2019-08-28%2019.39.00.jpg?1606306133)
UPDI-Programmer/Debugger (Photo von MCUdude aus dem Tindie shop)
Zusammenfassung und Fazit
Mit diesen Informationen sollte es dir leichtfallen, jeden AVR-Debugger einzuordnen, der auf deinem Schreibtisch landet. Wenn du dir einen neuen Debugger kaufen willst, bietet der MPLAB SNAP das beste Preis-Leistungs-Verhältnis. Man bekommt ihn für unter 10 €, und er kommt mit allen AVR-MCUs zurecht. Mit Adapterplatinen und Versand kann der Preis allerdings schnell auf 50 € steigen.
SNAP mit Adapter-Board (eigenes Photo)
Als Alternative empfehle ich den Atmel-ICE, der inzwischen für unter 90 € erhältlich ist und alle Adapter bereits mitbringt. Er ist deutlich schneller als der SNAP und macht außerdem einen robusteren Eindruck.
Das Beitragsbild wurde mit Hilfe von ChatGPT erzeugt.
Schreibe einen Kommentar