Benötigen Sie eine Erklärung zum Flashen von HEX-Dateien auf ATmega32u4 über das AVR109-Protokoll

Ich bin kein Elektronikexperte, verzeihen Sie mir also, wenn ich die Begriffe in meiner Frage falsch verwende oder wenn meine Frage Ungenauigkeiten und/oder Fehlinterpretationen darüber enthält, wie ein Leonardo-Board funktioniert. Korrekturen sind natürlich willkommen.

Ich versuche, einen sehr einfachen Chip-Flasher zu schreiben, der es bei einer HEX-Datei über seinen Bootloader auf einem Leonardo-Board flashen kann. Ich verstehe, dass der Arduino Leonardo einen ATmega32u4 verwendet und dass der Bootlaoder das AVR109-Protokoll verwendet .

Basierend auf diesen Informationen war ich in der Lage, einen Code zu schreiben, der Bytes auf dem Board flasht, aber einmal geflasht, funktioniert der Code nicht.

Mein Code sieht ungefähr so ​​aus:

  1. Analysieren Sie die (Intel) HEX-Datei in eine Darstellung, wie der Speicher auf dem Chip aussehen sollte (dh für jeden Datensatz extrahiere ich die Speicheradresse, in die geschrieben werden soll, und die Daten im Datensatz).
  2. Für jedes Paar Bytes in dieser Darstellung gebe ich eine set memory addressAnweisung aus, gefolgt von einem write low byte, gefolgt von einem write high byte.
  3. Alle 256 auf diese Weise geflashten Bytes erteile ich eine write pageAnweisung.

Es fällt mir schwer, herauszufinden, was ich falsch mache, weil ich mir bei keinem dieser Schritte sicher bin. Schritt 1 erzeugt Daten, die OK aussehen (da man hier und da einige bekannte Zeichenfolgen sehen kann):

Geben Sie hier die Bildbeschreibung ein

... aber wenn ich meine Daten mit der gleichen HEX-Datei vergleiche, die von AVRdude geflasht und wieder vom Chip geladen wurde, sind die beiden sehr unterschiedlich .

Schritt #2 funktioniert (der Bootloader antwortet bei jedem Befehl mit einem 0xD-Byte, aber ich weiß nicht, ob ich das Richtige tue, indem ich das niedrige Byte vor dem hohen flashe .

Schritt Nr. 3 scheint auch gut zu funktionieren, aber ich bin mir nicht sicher, ob Speicherseiten effektiv 256 Byte groß sind (ich habe diese Zahl aus dem Datenblatt des Chips abgeleitet, Tabelle 28-11).

Ich bin jedem sehr dankbar, der meinen "Algorithmus" überprüfen und Feedback dazu geben könnte, was ich richtig oder falsch mache und wo häufige Fehlerquellen bei dieser Art von Anwendung liegen.

Nur zur Verdeutlichung, ist das Bild ein Dump des ATmega-Speichers, nachdem Sie mit Ihrem Programm geschrieben haben? Sie sagen, dass die von AVRdude geladenen Daten unterschiedlich sind. Könnten Sie auch ein Bild davon posten, was von AVRdude geladen wird? Haben Sie sich die AVRdude-Quelle angesehen und mit Ihrer verglichen, um zu sehen, was anders gemacht wird?
@embedded.kyle Ich muss zurück nach Hause, um Sachen zu posten/testen... danke fürs Erste! Ich werde die Frage in ein paar Stunden aktualisieren. :)
Da AVRdude Open Source ist, könnte das Studium dessen, was es tut, ein Weg zur Lösung Ihrer Fragen sein.
Als ich einen Upload über USB benötigte (ich nehme an, Sie benötigen auch 32u4 über USB), habe ich versucht, AT90USBxxxx über den AVR109-Bootloader über USB zu programmieren. Aber ich fand, dass es fehlerhaft und unzuverlässig war, daher habe ich Standard-Stk500 über USB mit der neuesten LUFA-Bibliothek verwendet und bin zufrieden. Ich mag AVR109 nicht (und ein fast identisches Protokoll für noch ältere Geräte).

Antworten (3)

Ich habe dfu-programmer erfolgreich unter Linux (unter Verwendung eines "Bare-Bone" atmega32u2/atmega32u4) von der Befehlszeile aus verwendet. Es ist also sehr einfach, es in eine Makefile.

Ein Zitat von dieser Website:

dfu-programmer-0.6.2.tar.gz enthält den Quellbaum für dieses Projekt. Laden Sie diese herunter, um sie auf einem Linux/Unix/Mac-System zu erstellen und zu installieren.

Sie sollten es also auf einem Mac erstellen können. Oder Sie schauen in den Quellcode.

Die AVR109-Dokumentation ist nicht sehr klar, aber zwischen der AVR109-Dokumentation und dem avrdude-Quellcode habe ich einen einfachen Java-Code geschrieben (mit jssc für seriell), um auf AVR-Geräten in den Flash zu schreiben. Der spezifische Code für die Kommunikation mit dem Gerät und das Lesen der .hex-Datei (nicht alle Funktionen von .hex-Dateien werden unterstützt) finden Sie hier . Ich habe es nicht gründlich getestet, aber es hat auf dem Gerät (BrainLink), mit dem ich es verwendet habe, korrekt geschrieben und gelesen.

ps In Bezug auf Ihre spezifischen Punkte benötigt AVR109 immer zuerst das High-Byte (sowohl für Adressen als auch für Blockgrößen). Außerdem ist die Adresse in Worten, nicht in Bytes, also muss die Byte-Adresse durch zwei geteilt werden. Und bevor Sie Flash schreiben, müssen Sie den Flash löschen.

Musste den Code aktualisieren: Ich habe vergessen, dass man zuerst den Flash löschen muss.

Wenn Sie einen Chip-Flasher nur zum Programmieren herstellen, sollten Sie sofort damit aufhören. Atmel stellt ein Dienstprogramm namens FLIP bereit. Es flasht Hex-Dateien für Sie von direktem USB auf die Chips, sofern der Chip On-Chip-USB unterstützt, wie z. B. die ATmega##U#-Familie.

Sie können das gewünschte Programm in Atmel Studio schreiben, das Hex speichern, Atmel FlIP öffnen und das Hex flashen.

FLIPP

Oh wow, das ist eine alte Frage!
Während FLIP Linux zu unterstützen scheint, scheint eine OSX-Version nicht angeboten zu werden, daher wäre die Portabilität ein Schlag dagegen, insbesondere wenn auf dem Poster anscheinend bereits der tragbarere AVRdude funktioniert ...
Wenn jemand Mikrocontroller-Programmierung (oder jede andere Art) unter OSX durchführt, wird er fast immer eine Linux- oder Windows-Partition auf demselben Computer haben. Wenn nicht, machen sie es falsch.
Ich hatte den Eindruck, dass iOS nur von OSX aus programmiert werden kann, also weiß ich nichts über "oder irgendeine andere Art" ...
Na ja, ich bin sicher, Sie können iOS-Sachen unter Linux schreiben. Bei Windows bin ich mir nicht sicher. Ich habe vor einiger Zeit versucht, loszulegen, aber ich erinnere mich, dass ich unter Windows auf Probleme gestoßen bin. Linux ist eine Art "Programmierer-Himmel" für die allgemeine Programmierung.
@ShannonStrutz - warum sollte ich eine VM starten wollen, um ein eingeschränktes Anbietertool auszuführen, wenn es portable und flexible Lösungen gibt, die nativ auf allen drei Plattformen kompiliert und funktionieren ? Die VM kommt nur dann zum Einsatz, wenn es keine effizientere Alternative gibt. Und Ihre Partitionslösung ist weitaus unbequemer als eine VM, da sie einen Neustart und den Verlust all Ihrer gewöhnlichen Tools erfordert.
Okay, das wird langsam nervig, seine AVRdude-Lösung funktioniert nicht. Er bekommt zwei separate Hex-Dateien ... Er sagt nie, dass er auf OSX ist. Sie müssen sich keine Gedanken über die Portabilität der Programmiermethode machen, denn wenn Sie Firmware flashen und diese an Endbenutzer verkaufen möchten, verkaufen Sie nicht die Software, sondern die vorprogrammierte Hardware. Wenn Sie es auf den Chip bekommen, funktioniert es.
Der Punkt, an dem ich diesen Flasher geschrieben habe, war, etwas Leichtes zu haben [zugegeben: nur ein vorkompiliertes Image mit Fleisch zu versehen], frei (wie in Freiheit) und als Bibliothek (Python) verwendbar. Also, danke für deinen Vorschlag, Shannon, aber meine Frage bezieht sich wirklich auf das Schreiben des Codes für das Flashen , nicht auf eine Möglichkeit, Bilder zu flashen.
Benötigen Sie eine Erklärung zum Flashen von HEX-Dateien auf ATmega32u4 über das AVR109-Protokoll
AntwortenHierDatenschutz-Bestimmungen1y, 0v