ich mache gerade die ersten Schritte mit einem AVR64DD28 auf einer kleinen selbstgemachten Experimentierplatine mit Minimalbeschaltung (Plan im Anhang).
Das Board läuft gerade mit am Eingang des 7805 angeschlossenen 9 Volt vom Labornetzgerät, am Ausgang und damit VDD des AVR liegen gemessene 5,0 V an.
Angeschlossen am UPDI des AVR64DD28 habe ich ein ATtiny416 Xplained Nano mit mEDBG, verbunden mit meinem Windows-PC, auf dem das Microchip Studio 7.0.2594 läuft. Öffne ich Tools → Device Programming und stelle auf AVR64DD28 und mEDBG ein, wird das Device auch korrekt erkannt und die Fuses werden erfolgreich ausgelesen, siehe den Screenshot.
Versuche ich nun aber, Fuses zu ändern, erhalte ich die angehängte Fehlermeldung. Anscheinend ist das Verifizieren der geschriebenen Fuses fehlgeschlagen.
Woran könnte das liegen? Ich habe es bereits an zwei PCs und mehrfach mit zwei verschiedenen AVR-Exemplaren versucht, jedesmal erhalte ich die Fehlermeldung, und komme einfach nicht weiter ...
Zugegeben, die Erfolgswahrscheinlichkeit ist sehr gering, dafür ist aber auch der Aufwand ebenfalls minimal (und solange sich kein anderer meldet): versuchsweise 100 kOhm von UPDI nach Vdd anschließen.
Zugegeben, die Erfolgswahrscheinlichkeit ist sehr gering, dafür ist aber
auch der Aufwand ebenfalls minimal (und solange sich kein anderer
meldet): versuchsweise 100 kOhm von UPDI nach Vdd anschließen.
Habe es gerade ausprobiert, hat leider nicht geholfen.
Trotzdem danke für die Antwort.
Nachtrag: VDDIO2 ist übrigens per Jumper mit VDD=+5V verbunden; das hatte ich vergessen zu erwähnen.
Woher kommt der rote Rahmen? Das ist ein Diskrepanz-Hinweis.
Der rote Rahmen ist irreführend, er war auch da, als das Flashen meiner ATtinys erfolgreich verlaufen ist. Scheint ein Bug des Microchip Studios zu sein.
Ich habe den leisen Verdacht dass die Programmer Firmware zu alt ist.
Ja, diese Vermutung kam bei mir inzwischen auch schon auf ...
Leider schweigt sich die Dokumentation von Microchip[1][2] scheinbar darüber aus, welche Devices genau unterstützt werden, und ob/wie die Firmware des auf dem Board vorhandenen „mEDBG“ aktualisiert werden kann. Jedenfalls konnte ich eben dazu nichts finden.
Habe das dort aufgeführte Kommando ausgeführt (siehe Screenshot), was erstmal erfolgversprechend schien; allerdings wird im Device-Programming-Dialog im Studio nachher dieselbe Version wie vorher angezeigt (1.0d), und der erneute Versuch, die Fuses des AVR64DD28 zu ändern, scheiterte wieder an derselben Fehlermeldung. So war die Firmware des mEDBG wohl bereits auf dem letzten Stand …
Laut älteren Thread soll das Pkob Nano Pack das Passende sein. Guck einfach mal rein. Endung. zip anhängen und entpacken.
Ohne Gewähr. Umsichtig agieren.
Laut älteren Thread soll das Pkob Nano Pack das Passende sein.
Dieses enthält allerdings nur "nedbg_fw.zip", daher habe ich noch das Package "mEDBG support" geladen und geöffnet, darin befindet sich "medbg_images.zip". Dieses habe ich erfolgreich in das mEDBG geflasht – danach wird aber immer noch Firmware Version 1.0d angezeigt und es kommt wieder derselbe Fehler …
Ich habe mein AVR128DB48 Curiosity Nano rausgekramt. Darauf ist die Firmware Version laut Microchip Studio 1.19 drauf. View > Available Microchip Tools > rechts nedbg. Versionsangabe nicht verwechseln mit der Pack Version. Microchip Studio und MPLAB IDE wollen die Firmware nicht updaten. Das Problem hatte ich schon bei meinem Atmel ICE festgestellt.
!!! Ich beschreibe es für mein Curiosity Nano. Du musst gedanklich und praktisch bei medbg bleiben !!! :-)
Jetzt gibt es 2 Möglichkeiten das manuell zu machen.
a ) Python
Habe ich sowieso installiert. Die Umgebungsvariablen sind auch alle eingerichtet.
Man muss "pydebuggerupgrade" nachinstallieren.
https://pypi.org/project/pydebuggerupgrade/
Die Option 'latest' funktioniert nicht. Ich habe das aktuelle PKOB nano Pack (Microchip.nEDBG_TP.1.14.751.atpack) runtergeladen. Das ist die nedbg Firmware. Zum .zip umbenannt und daraus die Datei nedbg_fw.zip rausgezogen und in meinen Windows User Ordner abgelegt. In der device_support.xml Datei stehen übrigens alle unterstützten Controller drin.
CMD geöffnet und
pydebuggerupgrade -t nedbg nedbg_fw.zip
eingegeben. Ergebnis:
Upgrading nedbg (MCHP3372021800000303) to 'nedbg_fw.zip'
Upgrade to firmware version '1.31.39' successful
In Microchip Studio nachgeschaut, jetzt steht Firmware 1.1F statt vorher 1.19. mit "Microchip.nEDBG_TP.1.14.751.atpack" (PKOB nano)
Das Tool liegt im Verzeichnis:
C:\Program Files (x86)\Atmel\Studio\7.0\atbackend
CMD öffnen:
Verbindungscheck
atfw.exe -l
Es sollte ein nedbg auftauchen, los gehts
atfw.exe -t nedbg -a nedbg_fw.zip
Für einen Atmel ICE:
atfw.exe -a atmelice_fw.zip -t atmelice
Aktuelle Firmware laut Microchip Studio 1.2d mit Pack "Microchip.AtmelICE_TP.1.7.796.atpack"
Nachtrag:
In der device_support.xml der medbg Firmware sind die AVRxDD Typen gelistet. Noch ein Gedanke. Hast du den Teil "Programmer" vom restlichen "ATTINY416 XPLAINED NANO" getrennt? Nicht das der ATtiny416 dazwischen funkt, wenn du die fremde Ziel MCU AVRxDD flashen möchtest.
Hast du den Teil "Programmer" vom restlichen
"ATTINY416 XPLAINED NANO" getrennt? Nicht das der ATtiny416 dazwischen
funkt, wenn du die fremde Ziel MCU AVRxDD flashen möchtest.
Ja, die drei Widerstände in der Mitte (UPDI, RxD, TxD) hatte ich kurz nach dem Erwerb des Xplained-Nano-Boards (gemäß Manual) ausgelötet. Ich hatte es auch nur gekauft, um externe MCUs damit zu flashen. Das hat ja wie gesagt auch bisher immer funktioniert, mit mehreren ATtiny412 und 3216.
In der device_support.xml der medbg Firmware sind die AVRxDD Typen
gelistet.
Ja, seltsam, habe auch gerade nachgesehen. Dann kann es ja eigentlich auch nicht an der Firmware liegen, es sei denn, sie ist buggy …
Ich wüsste aber auch nicht, woran es sonst liegen könnte. Wobei … sind die Leitungslängen bzw. Steckverbinder für UPDI irgendwie kritisch? Ich verwende da solche billigen 20-cm-Dupont-Jumperkabel. Hat bisher (also bei den ATtinys) immer funktioniert.
woher sind deine Dupont Kabel? Meine Erfahrung mit meinen China Dupont sind schlecht. Ich muss alle nachpressen. Ich habe sonst nur Kontaktprobleme. Mach mal sachte die schwarze Hülse runter und prüfe ob die Litze sauber verpresst ist. Meine sind nur an der Isolierung gepresst und die zarte Litze liegt am eigentlichen Crimpkontakt nur zart an. Biegen und verwinden des Kabel reicht damit der Kontakt nicht mehr da ist. Man kann auch Durchgang messen und am Kabel spielen.
Mein selbstgebautes Kabel vom Atmel ICE ist 30cm lang. Ist altes 80pol. IDE Festplattenkabel. Dazu kommen nur wenige Zentimeter Dupontkabel inkl. Adapterplatine. Diese Kombination macht keine Probleme. Du kannst im Microchip Studio noch notfalls den Takt fürs Flashen reduzieren.
Zuerst hatte ich sehr billige (aus so einem trennbaren Flachbandkabel, von irgendeinem eBay-China-Händler), gerade habe ich sie nochmal durch bessere ersetzt (Joy-It, Reichelt), die einen etwas zuverlässigeren Eindruck erwecken (kommen aber sicher auch aus China, wie ja so ziemlich alles inzwischen). Zudem noch den Takt auf 32 kHz reduziert. Hat aber nichts genützt, immer noch derselbe Fehler.
Ich denke, dass es eher nicht daran liegt – zum einen habe ich jetzt schon sehr viele verschiedene Jumperkabel benutzt, da müssten ja wirklich alle defekt sein, und zum anderen wird ja die MCU am Anfang korrekt erkannt und die Fuses werden auch erfolgreich ausgelesen. Es ist ja wirklich nur der Schreibvorgang, der irgendwie Probleme macht.
deine Logik ist für mich erstmal verständlich. Du könntest probieren eine harmlose Fuse zu ändern. Um zu sehen ob der Fuse Schreibvorgang auch fehlschlägt.
Bspw. EEprom EESAVE ein/ausschalten. Oder BOD Level Spannung ändern aber nicht aktivieren. Könnte zur Fehlersuche beitragen. Unabhängig ob man die Fuse lesen kann oder nicht. Die Platine haste durchgemessen auf Kurzschlüsse an allen Pins o.ä.? Spannung liegt sauber an? Es gibt manchmal Effekte, die kann man sich erstmal nicht erklären.
Ansonsten kann ich da aktuell nicht weiterhelfen. Tut mir leid. Da müssen andere ran. Könntest noch ein Bild der Platine zeigen? Vielleicht fällt jemanden etwas auf. Kommt Zeit kommt Rat.
Die Platine haste durchgemessen auf
Kurzschlüsse an allen Pins o.ä.? Spannung liegt sauber an?
Also alles auf Kurzschlüsse geprüft habe ich noch nicht, aber die Platine nach dem Löten sehr sorgfältig auf Lotbrücken nach Sicht kontrolliert, und die Abstände von Leiterbahnen zu Massefläche hatte ich auch relativ groß eingestellt. Kann ja nochmal mit dem Durchgangspiepser nachprüfen (nach Herausnehmen des AVR natürlich) ...
Die Betriebsspannung ist sauber, kommt ja direkt aus dem 7805 on-board, habe gerade nochmal mein DSO dran gehängt und konnte keine messbare Restwelligkeit feststellen, ist also praktisch nicht vorhanden.
Fotos der Platine habe ich mal angehängt – würde keinen Schönheitspreis gewinnen, sind noch Flussmittelreste drauf, aber elektrisch sollte es eigentlich OK sein. Ist halt einseitig, entsprechend sind die Masseverbindungen nicht sooo gut wie man es doppelseitig hinbekommen könnte, aber ich denke, das dürfte nicht das Problem sein, oder?
Fuse schreiben geht auch nicht, dann wird das Auslesen nach schreiben zum Vergleich fehlschlagen. Es kommt wahrscheinlich nicht das an was geschrieben werden soll.
Ich schau mir das Morgen nochmal genauer. Die Flussmittelreste sollten jedoch runter. Sieht wie klassisches Kolophonium aus, was Kriechströme zwischen den Lötpins zulassen kann. Habe ich alles schon gehabt, gerade bei hochohmigen Eingängen und sehr schwach belasteten Ausgängen. Da blinkte die "Transistor verstärkte" Nachbar-Led plötzlich mit. Grund waren Rückstände vom Löten, hatte nicht richtig sauber gemacht.
Die Flussmittelreste sollten
jedoch runter. Sieht wie klassisches Kolophonium aus, was Kriechströme
zwischen den Lötpins zulassen kann.
Hmm, das war „Löthonig“, enthält Kolophonium. War mir noch nicht bekannt, dass das Kriechströme verursacht. Werde dann später die Platine reinigen – ich habe so eine Dose „Leiterplattenreiniger“ von Kontakt Chemie in meiner Haupt-Werkstatt herumstehen, da komme ich allerdings erst voraussichtlich übernächstes Wochenende ran (bin gerade an meinem Zweitwohnort). Bis dahin muss das also noch warten …
Funktioniert irgend ein anderes Kommando z.B. Flash auslesen oder chip
erase?
Habe gerade "Erase Chip" ausgeführt, es wurde "OK" zurückgemeldet.
Danach habe ich den Flash ausgelesen – ebenfalls "OK". Das Resultat habe ich mal angehängt – ist das plausibel nach einem Chip Erase? Es ist jedenfalls nicht alles null (ob das so sein muss, entzieht sich momentan meiner Kenntnis, ich habe mich bisher noch nicht mit der genauen Flash-Organisation auseinander gesetzt).
Nachtrag: Ich habe jetzt einen AVR64DD28 und 100n-Kerkos aufs Steckbrett gesetzt und alle GNDs und VDDs sowie UPDI mit dem Xplained Nano verbunden; ich erhalte dasselbe Ergebnis, also diesen Fehlercode 20000 nach dem Versuch, eine Fuse zu ändern. Es muss also wohl definitiv an diesem mEDBG auf dem Xplained Nano Board liegen.
die Hide-Option hast du auf false gesetzt? Ich habe das gleiche Problem bei andern UPDI-AVRs gehabt, als ich den Curiosity Nano Atmega4809 als Programmer genutzt habe.
Vllt bringts ja was.
Bisher noch nicht, hab es eben auf false gesetzt, danach war das Device-Eingabefeld mit AVR64DD28 bereits ausgefüllt, was ich bisher jedesmal wieder manuell machen musste, und der rote Rahmen ist verschwunden.
Trotzdem wieder derselbe Fehler: Error 20000 nach dem Versuch, eine harmlose Fuse (BOD-Level) zu ändern.
Ich geb’s jetzt erstmal auf und lasse den AVR-DD ruhen, bis ich mir ein UPDI-Programmer-Tool selbst programmiert habe, was ich sowieso schon vorhatte.
Was ich aus dem bisherigen Verlauf nicht herauslesen konnte: haben Sie versucht, ein einfaches LED-Blinkprogramm auf den DD zu bekommen? Ich meine, der erste Gehversuch mit einem neuen uC-Typen ist normalerweise nicht das Ändern der Fuses.
Lässt sich die IDE zwingen, den 'DD' als 'DA' oder 'DB' zu behandeln? Memory-Map ist ja gleich.
die Device ID Prüfung umgehen? Wenn die falsch wäre würde die MCU Auswahl scheitern. Falls der Programmer in Verdacht steht, dann einmal bitte mit PythonUpdi probieren. Zusätzlich ist nur ein Widerstand oder Diode notwendig und ein USB Serial Adapter.
ich habe den Thread nochmal komplett gelesen und fasse zusammen. Du kannst mit dem mEDBG ATtinys flashen aber keine AVR Typen? Welche AVR Typen hast du probiert? Probiere auf jeden Fall nochmal einen unabhängigen Programmer, den besagten pyupdi, Stichwort pymcuprog.
Am Schaltplan kann ich keine Fehler sehen, diesbezüglich schon gar nicht.
haben Sie
versucht, ein einfaches LED-Blinkprogramm auf den DD zu bekommen?
Noch nicht – das erste, was ich mit einem fabrikneuen AVR mache, ist mittlerweile, den BOD mit einem der Betriebsspannung angemessenen Level zu aktivieren. Das kommt bei mir noch vor dem Flashen eines Programms. Aber ich kann natürlich auch versuchen, ein Blinkprogramm in den AVR64DD28 zu laden – dachte nur, das hätte gar keinen Sinn zu probieren, wenn nichtmal die Fuses gesetzt werden können.
Falls der Programmer in Verdacht steht, dann einmal
bitte mit PythonUpdi probieren. Zusätzlich ist nur ein Widerstand oder
Diode notwendig und ein USB Serial Adapter.
Ja, von pyupdi hatte ich schon mal gelesen (aber nicht näher verfolgt, da ich eine gewisse Aversion gegenüber Python hege), werde mich aber zeitnah darüber informieren und es nochmal damit versuchen.
Bisher nur die zwei AVR64DD28 im DIL-Gehäuse (wurden bei Mouser.de gekauft). In meiner Nebenwohnung habe ich noch zwei neue AVR128DB28 liegen, da komme ich aber erst übernächstes Wochenende wieder ran.
Ich sehe trotzdem eine gewisse Wahrscheinlichkeit, dass ein Programm geflasht werden kann - oder zumindest das Verhalten der IDE bei diesem Versuch einen weiteren Hinweis auf das eigentliche Problem gibt.
habe ich noch zwei neue AVR128DB28
Diese könnten eher akzeptiert werden, sind ja (ein oder zwei Jahre) älter.
Wie dem auch sei - ich musste beim Einfügen der 'DD'-Reihe in mein Selbstbauprogrammiergerät lediglich den Klartext für die ausgelesene Signatur ergänzen, ansonsten entsprach alles einem 'DA' oder 'DB'.
Ich sehe trotzdem eine gewisse Wahrscheinlichkeit, dass ein Programm
geflasht werden kann - oder zumindest das Verhalten der IDE bei diesem
Versuch einen weiteren Hinweis auf das eigentliche Problem gibt.
Ich habe nun versucht, das angehängte primitive Blinkprogramm zu flashen, und habe wieder nach dem (scheinbar erfolgreichen) Chip Erase eine Fehlermeldung erhalten und das Flashen wurde abgebrochen; siehe angehängte Screenshots.
Falls der Programmer in Verdacht steht, dann einmal
bitte mit PythonUpdi probieren. Zusätzlich ist nur ein Widerstand oder
Diode notwendig und ein USB Serial Adapter.
Ich habe eben auf meinem Raspberry Pi 4 dieses „pymcuprog“-Package zum Laufen gebracht (hat eine Weile gedauert, da ich bisher noch keinerlei Erfahrung mit „pip“ und allgemein wenig Erfahrung mit Linux habe).
Nachdem ich es geschafft hatte, pymcuprog erfolgreich in der Bash aufzurufen, habe ich meinen MCP2221-USB-Serial-Adapter (dessen zugewiesene Linux-Device-ID ich ebenfalls geschafft hatte zu finden) nach der Anleitung mit einem 1k-Widerstand und UPDI des AVR64DD28 verbunden und das ping-Kommando von pymcuprog mit entsprechenden Parametern (-t uart -u /dev/ttyACM0 -d avr64dd28) aufgerufen. Nach einigen Sekunden und Blinken der Rx-/Tx-LEDs am MCP2221 beendete sich pymcuprog dann schließlich mit der Fehlermeldung ERROR: UDPI initialization failed (oder so ähnlich).
Keine Ahnung, woran das nun wieder liegen könnte. Auch ein Ping-Test an einem vorher und nachher funktionierend getesteten ATtiny3216 mit gleicher Beschaltung schlug mit derselben Fehlermeldung fehl. Verschiedene Taktraten habe ich ebenfalls an beiden MCUs getestet, ohne Erfolg. Das (selbstgemachte) MCP2221-Board funktioniert ebenfalls einwandfrei, ich habe es nachher nochmal erfolgreich am UART des ATtiny3216 getestet.
So langsam vergeht mir die Lust, mich mit mEDBG (und pymcuprog) herumzuärgern. Beides bringt mir weder Lern- noch Spaßeffekt. Daher werde ich den AVR_DD erst einmal zu den Akten legen und mich dem Studium des UPDI-Protokolls widmen, um dann einen UPDI-Programmer selbst zu implementieren und dabei auch Programmier-Lernfortschritte zu machen. Das hatte ich mir ja wie gesagt ohnehin schon als Projekt vorgenommen.
Trotzdem herzliches Dankeschön für alle gut gemeinten Antworten und Vorschläge.
Nach dem Eingangsfehler hatte ich schon gesucht, man findet nicht viel. Außer das manche Chip Erase machen was erfolgreich gewesen sein soll. Nur ist chip erase vorm flashen Standardeinstellung.
Die letzte Fehlermeldung sagt aus er konnte nicht beschrieben werden. Brauchbares findet man dazu auch nicht.
Ganz doof gefragt, Du hast nicht Ausversehen UPDI per Fuse disabled?
Ansonsten wenn ich es nicht genauer wüßte, würde ich vermuten der DD ist defekt, ist unwahrscheinlich aber möglich. Mach bitte nächste Woche noch einen Versuch mit deinem DB. Wenn immer noch nichts funktioniert, kannst du mir gern einen zusenden und ich teste den. Schicke ich dir auch zurück wenn du willst. Schreib mir eine PN dafür. Außer du hast jemanden in der Nähe mit Atmel ICE o.ä. wo du hingehen kannst. Dann wüßte man erstmal gesichert liegt es am DD oder doch an etwas anderem.
Zugegeben die Situation ist komisch, ich denke wir können dich alle verstehen.
(...) und mich dem Studium
des UPDI-Protokolls widmen, um dann einen UPDI-Programmer selbst zu
implementieren und dabei auch Programmier-Lernfortschritte zu machen.
So ähnlich hab' ich's auch gemacht, basierend auf dem FT230x und mich von diesem Projekt inspirieren lassen, da ich C favorisiere:
https://github.com/Polarisru/updiprog
Ansonsten wenn ich es nicht genauer wüßte, würde ich vermuten der DD ist
defekt, ist unwahrscheinlich aber möglich.
Hmm, ist schon ziemlich unwahrscheinlich, dass wirklich beide Exemplare defekt sind … Aber wer weiß.
Ich verstehe auch nicht, dass pymcuprog selbst meinen ATtiny3216, der eindeutig OK ist, nicht erfolgreich pingen kann – da muss irgendwas im Argen liegen. Kann mir nicht vorstellen, wo da der Fehler liegt. MCU i.O., USB-Serial-Adapter OK, … Aber irgendwie muss es ja an mir bzw. meinem Equipment liegen, wenn es bei anderen Usern funktioniert.
Naja, halb so wild, ich werde schon irgendwann der Ursache auf die Schliche kommen, da bin ich ziemlich sicher. Ich melde mich dann auf jeden Fall hier in diesem Thread wieder und werde berichten.
(...) und mich dem Studium
des UPDI-Protokolls widmen, um dann einen UPDI-Programmer selbst zu
implementieren und dabei auch Programmier-Lernfortschritte zu machen.
So ähnlich hab' ich's auch gemacht, basierend auf dem FT230x und mich
von diesem Projekt inspirieren lassen, da ich C favorisiere:
https://github.com/Polarisru/updiprog
Danke für den Link, werde ich mir ansehen. Ich persönlich ziehe Assembler bei AVRs vor, weil es mir Spaß macht, zu wissen, was genau die CPU mit welchen Registern etc. tut. Bei der 8-bit-AVR-Architektur ist das auch noch ziemlich gut zu überblicken, finde ich. Aber das ist halt Geschmackssache. Für den RP2040 bspw., mit dem ich auch noch vorhabe mich zu beschäftigen, werde ich auch in C programmieren.
Nein, ich bin wirklich nur an die BOD-Fuses ran gegangen,
alles andere habe ich nicht berührt.
Wenn, warum auch immer, die ursprüngliche Version der IDE SYSCFG0 mit einem Default-Wert einer älteren Version geschrieben hat und sich dabei an "Note: When writing the fuses, all reserved bits must be written to ‘0’." hielt, ist nun UPDI gesperrt (und nur mit "Applying an HV pulse on RESET will reconfigure the UPDI pin to UPDI function mode, thereby overriding the configuration in the SYSCFG0 fuse" freizugeben) - was hat sich Microchip bei "Value 0: GPIO UPDI pin is configured as GPIO" bloß gedacht?
Wenn damit auch ein funktionierender ATtiny nicht ansprechbar ist, dann ist am "Setup" was faul. Masseverbindungen vorhanden? Problem mit 3,3V <> 5V? Viel mehr kann ich aus der Ferne nicht machen. Ich wünsche maximale Erfolge. Wenn der Fehler gefunden wurde kannst du ihn gern kundt tun.
Yô, und meinereiner war natürlich prompt darauf hereingefallen: wollte nur mal schnell, wie üblich, EESAVE setzen, versehentlich das AVR128DB28 Datenblatt erwischt, und schon durfte ich anschließend das 12 V-Platinchen hervorkramen.
Okay, zugegeben, mein Fehler, und die HV-Rettung ist ja geradezu bequem geworden, verglichen mit den älteren Controllern, trotzdem: so unnötig wie ein Kropf.
für pyupdi hast du auch alles Notwendige
[…]
installiert?
Habe gerade nochmal meinen Raspi hochgefahren und gecheckt, es war alles bis auf 'pylint' bereits installiert. Nachdem dann auch dieses noch installiert wurde, habe ich nochmals den Versuch unternommen, meinen ATtiny3216 zu pingen – wieder scheiterte es mit folgender Meldung:
Wir hoffen das Beste für den TO. Hat zur Zeit zu viele Baustellen
gleichzeitig.
Vielen Dank! Ja, ich arbeite tatsächlich abwechselnd auch noch an anderen Projekten, z.B. designe ich gerade eine Platine für meinen künftigen Ätzküvetten-Temperaturregler mit einem ATtiny3227 (meine erste doppelseitige LP, zur Fertigung bei JLCPCB). Deshalb ist es nicht so tragisch, wenn ich hier erstmal nicht weiterkomme.
inzwischen habe ich ein kleines Programm (siehe Anhang) für einen ATtiny3216 zustande gebracht, das via UPDI den System Information Block eines angeschlossenen AVRs ausliest und über UART ausgibt.
Nun möchte ich im nächsten Schritt die Fuses des Ziel-AVRs lesen und schreiben. Allerdings finde ich in den Datenblättern von AVR64DD28 und ATtiny416 (den ich ebenfalls momentan noch als Testobjekt liegen habe) wenig bzw. keine für mich eindeutigen Angaben zu den absoluten Adressen der Fuses im Flash. Auf [1], S. 46, steht „0x1280 | FUSES | Device-specific fuses“, wobei ich mir unsicher bin, ob sich das wirklich auf den Flash bezieht, oder auf die Register im RAM, in die während RESET die Fuse-Werte kopiert werden. Und an anderen Stellen werden nur Offsets für die Fuse-Bytes angegeben.
Ich habe bisher noch nicht direkt mit Lesen/Schreiben des Flash-Speichers gearbeitet und kenne mich da noch nicht aus. Daher würde ich mich über Tipps freuen, wo genau ich die Adressen finde, die ich beim Lesen und Schreiben der Fuses via UPDI verwenden muss. Komme da momentan einfach nicht weiter …
In der …def.inc hatte ich zwar auch schon nachgesehen, aber ich dachte irgendwie, dass diese Adressen sich auf den RAM beziehen … Weiß auch nicht, wie ich darauf komme.
Nun denn, dann schaue ich jetzt mal, was ich meinen beiden AVR64DD28 so entlocken kann.
um einmal das Schema F der Register im Manual näher zu bringen.
In allen Kapiteln sind für die Register immer nur die Offsetwerte für die Adresse angegeben. Die Basisadresse der Hardwareeinheiten stehen hier im Kapitel 9 - Seite 64. Die Fuses im Bsp. Seite 65 haben die Basisadresse 0x1050. Dann geht man ins Fuse Kapitel o.a. und addiert die Offsets der gewünschten Register.
Das mag auf den ersten Blick verkompliziert sein. Ist es aber auf dem 2. Blick nicht mehr. Wenn man die aktuellen Serien vergleicht, sind die Offsets fast immer gleich, ich lege jetzt nicht die Hand ins Feuer, aber es ist ziemlich offensichtlich. Man kann sehr einfach Libs für eine Serie schreiben und passt für eine andere Serie nur die Basisadresse an.
Hallo Veit, danke für die Erläuterung – mir ist nun klar, wie die Adressen strukturiert sind. Ich hatte irgendwie Tomaten auf den Augen.
Inzwischen habe ich geschafft, die Fuses aus dem ATtiny416 meines Xplained-Nano-Boards auszulesen; siehe den angehängten Screenshot. Das Lesen aus dem AVR64DD28 scheiterte allerdings – an den Adressen der Fuses wurde überhaupt keine Antwort zurückgegeben, an ungültigen Adressen ("Reserved"-Block) lieferte das UPDI scheinbar zufällige Bytes als Antwort auf die LDS-Anweisung.
Mir kam infolgedessen nun der Verdacht auf, dass meine beiden AVR64DD28 eventuell LOCKED sind. Das würde ja die fehlende Antwort und die Fehlermeldung beim Verifizieren der Fuses erklären. Ich werde gleich mal probieren, einen CHIPERASE durchzuführen, und melde mich dann nochmal, ob das was gebracht hat …
Zum Locken müßte man laut Manual einen ungültigen Wert in das Lock.Key Register schreiben. Adresse 0x1040. Kann das zufällig passiert sein? Ein einziger gültiger Wert zum unlocken ist 0x5CC5C55C, alles andere sind ungültige Werte. Seite 58-61.
Von Configuration Change Protection dafür lese ich auch nichts. Seite 41.
Kannst du das Lock-Key Register im gesperrten Zustand auslesen?
Chip Erase soll entsperren, ich weiß aber nicht ob das Lock Key Register dabei automatisch auf Default "entsperrt" gesetzt wird. Oder man das selbst machen muss.
Chip Erase soll entsperren, ich weiß aber nicht ob das Lock Key Register
dabei automatisch auf Default "entsperrt" gesetzt wird.
Hmm, gute Frage: Aus dem Datenblatt des AVR64DD28, S. 564: "After a successful chip erase, the lock bits will be cleared, and the UPDI will have full access to the system." Das suggeriert ja erstmal, dass LOCK.KEY einfach nur auf 0x0000_0000 gesetzt wird? Dann müsste man noch manuell den Valid Key schreiben. Ich werde das ausprobieren; momentan bin ich noch dabei, meinen Code aufzuräumen, um die Handhabung zu verbessern …
Wie sollte das gehen? Der Controller wäre ja noch immer gesperrt,
folglich hätte UPDI keinen Zugriff auf die Lock-Bytes.
Ja, ich finde es auch seltsam, aber ich dachte, vielleicht merkt sich der AVR irgendwie, dass ein Chip Erase durchgeführt wurde und erlaubt bis zu einem Reset oder so den Zugriff auf die Lock-Bytes.
Oder es ist nur ein Formulierungsfehler im Datenblatt. Wird sich hoffentlich nachher herausstellen.
ich verstehe den gezeigten Text von Seite 564 so, dass mit "cleared" das Register auf Default, also unlocked gesetzt wird. Der Nachsatz
"... and the UPDI will have full access to the system."
unterstreicht das. Die ungültigen lock bits werden gelöscht.
Ansonsten wäre das in der Tat wie S.L. schreibt unlogisch und man würde sich im Kreis drehen. Was mich nur wundert ist, du hast doch bei den früheren Programmierversuchen immer chip erase durchgeführt. Der Controller sollte eigentlich entsperrt sein. 'grübel'
Leider muss ich nochmals eine Frage zu den Adressen stellen:
Wo finde ich denn die Basis-Adresse der UPDI-Register im RAM, vom UPDI-Adressraum aus gesehen? Die kann ich weder im Datasheet noch in der …def.inc finden.
Ich würde im Zuge des Chip Erase gern die Register UPDI.ASI_KEY_STATUS, UPDI.ASI_RESET_REQ und UPDI.ASI_SYS_STATUS lesen bzw. schreiben. Dazu sind unter "UPDI Register Description" natürlich wieder die Offsets angegeben, jedoch bin ich mir über die Basisadresse im Unklaren.
Wo ich z.B. jene der FUSEs finde, weiß ich nun – aber unter "Peripheral Address Map" gibt es keine Zeile "UPDI".
Gibt es nicht, bzw. ist 0. Die Zeile "Offset: ..." unter UPDI- 'Register Summary' ist etwas irreführend. Es handelt sich um Register innerhalb von UPDI, und auch nur innerhalb ansprechbar mit LDCS bzw. STCS.
ich habe in der Zwischenzeit viel Zeit mit dem Herumexperimentieren mit meinem UPDI-Testprogramm verbracht; was nun funktioniert, ist das Auslesen des System Information Blocks, das Lesen von UPDI-Registern mit dem LDCS-Befehl sowie (scheinbar) das Durchführen eines Chip Erase, wobei letzteres zwar einen ASI_SYS_STATUS von 0x20 am Ende liefert (d.h. LOCKSTATUS == 0), der AVR64DD28 danach aber trotzdem nicht auf LDS-Befehle antwortet (ebenso wie mein ATtiny416).
Der Soft-UART, den ich nach den Datenblatt-Spezifikationen des UPDI geschrieben habe, funktioniert; zumindest werden die Sendungen, die mein Programm erzeugt, vom angeschlossenen u. UPDI-entsprechend konfigurierten Oszilloskop richtig decodiert – ein Screenshot von einer LDS-0x1100-Anweisung ist angehängt.
Auf diese LDS-Anweisungen folgt leider keine Antwort, weder vom AVR64DD28 noch vom ATtiny416, mit dem ich ebenfalls teste. Ich kann mir nun einfach nicht erklären, warum. Der Empfang des SIB funktioniert ja: ich erhalte
1
AVR P:2D:1-3
vom AVR64DD28 und
1
tinyAVR P:0D:0-3
vom ATtiny416.
Da das Problem ja scheinbar nur bei den Anweisungen besteht, die aus mehr als einem Byte (ohne SYNCH) bestehen, habe ich bereits zwischen den einzelnen Bytes Abstände von zwei Idle-Bits oder sogar einem ganzen IDLE-Frame (also 12 High-Bits) eingefügt – ohne Erfolg. Ich weiß einfach nicht weiter, was noch das Problem sein könnte. Den derzeitigen Stand meines (hoffentlich hinreichend kommentierten) Assembler-Codes habe ich mal angehängt. Ich würde mich sehr über Hinweise freuen, was ich falsch gemacht haben könnte.
Ich habe noch ein paar Fehler beseitigt, die aber nichts mit dem LDS-Problem zu tun hatten. Den korrigierten Code habe ich angehängt.
Gerade habe ich auch noch mit einem ebenfalls nagelneuen AVR128DB28 von Mouser.de getestet: selbes Ergebnis, Ein-Byte-Anweisungen funktionieren, dagegen keine Antwort auf LDS-Instruktion. :(
Hmm - ich habe bislang immer zu den Tools des Herstellers gegriffen und bin dahin immer gut gefahren. Das ist zwar nicht die billigste Methode, aber die effizienteste, wenn das Zeugs laufen muss und man Geld damit verdient.
In Deinem Fall wäre das ein PICKIT 5 mit MPLABX. Ja, ich weiß, dass das in der AVR Community unbeliebt ist, aber das ist eben das, was Microchip aktuell anbietet und auch weiter pflegen wird. Das Studio ist EOL.
Ja, das ist schon eine Überlegung wert für mich, mir das anzuschaffen. Ist ja auch gar nicht soo teuer. Obwohl das alles für mich „nur“ Hobby ist und ich keinerlei Geld damit verdiene.
Mir geht’s allerdings momentan vorrangig darum, das UPDI-Protokoll zu verstehen und herauszufinden, wo der Fehler in meinem Code ist. Der Fehler muss ja bei mir liegen, denn die drei z.T. fabrikneuen AVRs können ja nicht alle kaputt sein ...
Versuche ich nun aber, Fuses zu ändern, erhalte ich die angehängte
Fehlermeldung. Anscheinend ist das Verifizieren der geschriebenen Fuses
fehlgeschlagen.
Hab das gleiche Problem mit SAM4E16E & SAMC21.
Egal ob mit SEGGER SAM-ICE oder ATMEL-ICE Programmer.
Klickst du "Program" scheint alles gut zu sein, klickst du dann "Verify" kommt deine Fehlermeldung.
Nutzt du jedoch die JLink.exe oder atprogram.exe und setzt die Fuses per Befehl direkt über die Konsole, dann funktioniert es.
Fazit:
Ich glaube da stimmt was mit dem Studio nicht.
Mal funktionierts und dann wieder ganz oft nicht.
Das Programm ist mir zu komplex, um es rein gedanklich nachvollziehen zu können.
Um es aber laufen zu lassen, fehlt mir (neben den Makros) die Hardware, ich habe hier aus der 'tinyAVR® 1-series'-Reihe nur den ATtiny1614, und der hat keinen PORTC. Bei den AVRmxyn fehlt mal PORTB, mal TCA. Kurzum: wenn Sie Ihr Programm so ändern, dass es auf dem ATtiny1614 läuft (u.a. PORTC -> PORTA), will ich mich gerne mit Ihrem LDS-Problem befassen.
Kurzum: wenn Sie Ihr Programm so ändern, dass es auf dem
ATtiny1614 läuft (u.a. PORTC -> PORTA), will ich mich gerne mit Ihrem
LDS-Problem befassen.
Hier die für den ATtiny1614 geänderte Version im Anhang, nun als kompletter Microchip-Studio-Projektordner incl. Build – ich hoffe, so ist es evtl. einfacher.
Die Datei /macros.asm/ ist nun auch mit dabei, hatte ich letztes Mal vergessen, sorry.
Vielen Dank an S. Landolt, dass Sie sich damit beschäftigen möchten.
Die Datei /updi.asm/ enthält die Timer-ISR für den Software-UART, sowie die Pin-Sense-ISR, welche nach einem Sendevorgang aktiviert wird und dann bei fallender UPDI-Flanke den Empfang auslöst. Zudem noch die Routine /updi_tx/, die das Senden der im UPDI-Puffer gespeicherten Bytes anstößt.
Die Datei /main.asm/ enthält das Programmgrundgerüst zur Kommunikation über UART mit einem PC-Terminal; die Hauptschleife ruft updi_tx entweder direkt oder über Subroutinen auf und liest dann das Empfangene aus dem Puffer.
Ich hoffe, der Code ist in Verbindung mit den Kommentaren so verständlich.
Gibt es hardwaremäßig etwas zu beachten?
Ich habe UPDI an PORTA_1 angeschlossen (per 1 kOhm, wie vorgegeben); zuvor das Programm auf interne 20 MHz umgestellt. Gebe '1' für '(1) Read SIB' und erhalte nach 5.2 s die Meldung "Error: Timeout while waiting for UPDI answer." (ebenso bei '2'), sowohl bei einem AVR16EB28 als auch bei einem ATtiny412. U= 3.3 V.
Gebe '1' für '(1) Read
SIB' und erhalte nach 5.2 s die Meldung "Error: Timeout while waiting
for UPDI answer." (ebenso bei '2'), sowohl bei einem AVR16EB28 als auch
bei einem ATtiny412. U= 3.3 V.
Habe gerade die Ursache gefunden: Zeile 42 in "main.asm" muss
1
.equ TARGET_UPDI_PINCTRL = PORTA_PIN1CTRL
lauten. Ich hatte vergessen, dort die Pin-Nummer von 0 auf 1 zu ändern (Target UPDI war bei mir PC0). Damit wurde der Pin Change Interrupt nicht ausgelöst und daher der Empfang nicht getriggert.
BTW, gibt es eigentlich irgendeine Möglichkeit, diese .equ-Direktiven beim Microchip-Assembler avrasm2 so zu gestalten, dass man bei mehreren Port-Register-Definitionen bzw. Pin-Zuweisungen diese Buchstaben/Zahlen nur einmal definiert und dann daraus die verschiedenen Symbole wie PORTX_VOUT, PORTX_VDIR, PORTX_PINYCTRL etc. automatisch ableitet? Ich hatte das schonmal erfolglos mit Makros versucht. Das würde zumindest solche Flüchtigkeitsfehler wie den obigen vermeiden helfen.
Ich hatte früher einmal etwas mit den Operatoren 'Stringification (#)' und 'Concatenation (##)' versucht, das hatte auch funktioniert, aber es war mir, um ehrlich zu sein, auf Dauer zu kompliziert bzw. es widerstrebte meiner gewohnten Denkweise.
PS:
So, nun erhalte ich schon mal bei '1' "tinyAVR P:0D:0-3" für den ATtiny412 - jetzt geht es an '3'. Das kann aber eine Weile dauern: "alter Mann ist kein D-Zug", sagten wir in der Mittelstufe und lachten; heute, nach vielen Jahrzehnten, ist mir das Lachen darüber vergangen.
Ein Fehler liegt in der Übergabe der Adresse: wenn ich statt 'temp1,temp0' z.B. YH,YL verwende, erhalte ich meist das richtige Ergebnis: "Address: 1101 Data: 92" oder auch "Address: 1285 Data: F7". Aber nur meist - manchmal kommt noch immer Timeout, und es ist mir noch nicht klar, unter welchen Umständen.
Hmm, das ist aber merkwürdig ...
Klingt erstmal danach, als wenn ich vergessen hätte, die Register temp0 und temp1 z.B. in der Timer-ISR zu retten. Habe ich aber gemacht – gerade noch mal alles kontrolliert.
Vergessen Sie dies erstmal, es könnte auch an meiner Hilfsausgabe liegen.
Das vordringliche Problem ist ohnehin das Timeout: vorhin trat es generell nicht mehr auf, nach Strom aus- und wieder einschalten ist es nun permanent da - ich arbeite dran, ich arbeite dran ...
Nachtrag:
Dasselbe bei einem neuen AVR32EA28 (mit '1' "AVR P:3D:1-3").
Ich setze mich morgen nochmals an Ihr Programm und melde mich, falls die beiden Letztgenannten auch erkannt werden.
Leider ist ein Vergleich mit meinem eigenen Programm schwierig, es hat eine völlig andere Struktur.
Habe ich probiert – leider ohne Erfolg, bei mir kam bei keinem meiner Versuche eine Antwort vom AVR128DB28.
Ich habe nun auch noch versucht, die „Start-Sequenz“ des mEDBG (UPDI low für ca. 50ms, high ca. 100ms, nochmal low ca. 50ms, danach das SYNCH-Frame), die ich auf meinem Oszi bemerkt habe, nachzuahmen – ebenfalls ohne Erfolg. :,(
Ich kann mir einfach nicht erklären, warum die AVRs auf den von meinem Programm gesendeten LDS-Befehl keine Antwort liefern – der Befehl wird ja von meinem Oszi korrekt decodiert … Weiß einfach nicht, was da falsch läuft. Zumindest die Signature-Bytes werden ja offenbar vom mEDBG korrekt ausgelesen und im Studio angezeigt. Sehr mysteriös, dass das mit meinem Programm nicht klappt.
Ja, zumindest dem ATtiny416 konnte ich mit meinem Programm mal u.a. die Fuse-Werte per LDS entlocken. Dann hatte ich einiges im Code umstrukturiert – „verbessert“, so dachte ich … – und nun geht es nicht mehr.
Ich kann mir aber beim besten Willen nicht erklären, woran das liegt. Habe den Code schon dutzende Male nach irgendwelchen Fehlern durchforstet … zumal das Software-UART-Output ja auf dem Oszi das gewüschte Ergebnis liefert …
Schon richtig, aber bei LDS wird die Grenze zwischen ASI und dem eigentlichen Controller überschritten; die Zustände Beider müssen zueinander passen.
Wie gesagt, ich setze mich morgen nochmals dran (halte mich an Edwin C. Bliss: 'Few problems resist an all-out-attack'); und schließlich habe ich selbst ja auch einen gewissen Erkenntnisgewinn.
Gerade an einem AVR128DB28 getestet: es funktioniert bei mir genau jedes zweite Mal, dazwischen wieder Timeout (getestet mit den Signature-Byte-Adressen 0x1100, 0x1101, 0x1102).
Aber immerhin schon ein Fortschritt. Vielen Dank für den Hinweis!
Mit dem AVR128DB28 scheint es so zu funktionieren. Mehrfach nacheinander wurden die Signaturbytes erfolgreich gelesen.
Leider geht es aber mit meinem ATtiny416 gar nicht, da kommt nie eine Antwort … Mysteriös. Kann sein, dass der eventuell geLOCKt ist. Allerdings bekomme ich ebenfalls bei der ChipErase-Sequenz ein Timeout.
PS:
Andererseits: warum sollte Ihr ATtiny416 überhaupt gesperrt sein?
Als das Auslesen mittels LDS mit meinem Programm noch funktionierte, wollte ich mal versuchsweise den ATtiny sperren, indem ich mittels des Menüpunkts "(4) Write fuse byte" irgendeinen Wert in LOCKBIT ungleich 0xC5 schrieb. Ich kann mich nicht mehr erinnern, ob das Entsperren danach geklappt hat. Gerade habe ich den ATtiny aber nochmal ans mEDBG geklemmt, welches die Signatur auslesen konnte. Demnach war der ATtiny also nicht gesperrt.
Ich habe mir nun vorgenommen, den Quellcode des /pymcuprog/ von Microchip[1] zu studieren, um hoffentlich mehr Einsichten in die Funktionsweise von UPDI zu gewinnen – was die Datenblätter nicht so richtig hergeben, wie ich finde. Mal sehen, inwieweit mir das mit meinen bescheidenen Python-Kenntnissen gelingt.
[1] https://github.com/microchip-pic-avr-tools/pymcuprog
Zumindest kommt dieses Programm ja wohl offiziell vom Hersteller und sollte damit ja die eigenen Spezifikationen erfüllen …
Nun, ich hatte wie Sie angefangen, nämlich mit dem Auslesen des SIB, damals noch auf einem ATmega1284P, TX und RX über diese Widerstand-Diode-Kombination an UPDI angeschlossen. Alles anhand des Datenblattes. Bald auf AVR128DA28 umgestiegen, und dort LBME und ODME der USARTs genutzt; was mir Ihre Einzelbitverarbeitung ersparte. Und ja, trotz Datenblatt war einiges nur durch Ausprobieren (neudeutsch: trial&error) zu meistern, sodass ich, wie Sie jetzt, Hilfe auf github suchte - und nur Unbrauchbares oder zu Kompliziertes fand; ist aber schon Jahre her, das mag heute anders aussehen.
Mit dem aktuellen Stand meines Programmes bin ich ganz zufrieden, und vielleicht baue ich demnächst noch das HV-Reset ein, obwohl ich es nicht benötige.
Ihnen wünsche ich viel Erfolg auf dem weiteren Weg zum eigenen Programm (und auch viel Glück, ich fürchte, Sie werden es brauchen), und verabschiede mich ...
Nun, ich hatte wie Sie angefangen, nämlich mit dem Auslesen des SIB,
damals noch auf einem ATmega1284P, TX und RX über diese
Widerstand-Diode-Kombination an UPDI angeschlossen. Alles anhand des
Datenblattes. Bald auf AVR128DA28 umgestiegen, und dort LBME und ODME
der USARTs genutzt; was mir Ihre Einzelbitverarbeitung ersparte.
Ja, ich dachte auch schon daran, dass ein Controller mit mehr als einem Hardware-USART vorteilhaft wäre – ich habe bereits viele ATmega328PB auf Lager, allerdings fehlt mir momentan noch ein Breakout-/Experimentier-Board für deren TQFP-32-Gehäuse (ist in Planung, werde ich demnächst bei JLCPCB fertigen lassen); somit blieb mir nur die Software-Lösung, die aber m.E.n. auch relativ /straight-forward/ gemacht ist.
Und ja,
trotz Datenblatt war einiges nur durch Ausprobieren (neudeutsch:
trial&error) zu meistern, sodass ich, wie Sie jetzt, Hilfe auf github
suchte - und nur Unbrauchbares oder zu Kompliziertes fand; ist aber
schon Jahre her, das mag heute anders aussehen.
Inzwischen bin ich – nach einigem Suchen im Dateiendschungel – fündig geworden, was die für mich interessanten Teile des pymcuprog-Sourcecodes betrifft:
Ihnen wünsche ich viel Erfolg auf dem weiteren Weg zum eigenen Programm
(und auch viel Glück, ich fürchte, Sie werden es brauchen), und
verabschiede mich ...
Dankeschön, sowohl für die guten Wünsche als auch für Ihre gewohnt wertvolle Hilfe! :)
Sooo, das LDS-Problem ist gelöst. Ich habe nach dem updi_enable eine Wartezeit von 25 ms eingefügt (nach einer LDCS-Anweisung, damit die Target-MCU nicht ihr UPDI per Timeout gleich wieder deaktiviert):
1
loop_readByte:
2
[...]
3
rcall updi_enable
4
; Send LDCS instruction, to keep UPDI alive:
5
clr tmp0
6
rcall sendLdcs
7
; Wait for answer bytes from Target UPDI:
8
loop_readByte_waitLdcs:
9
sbrc updiFlags, UPDI_FLAGS_TIMEOUT_bp
10
rjmp loop_timeout
11
sbrs updiFlags, UPDI_FLAGS_RXC_bp
12
rjmp loop_readByte_waitLdcs
13
; Give the target MCU a bit of time:
14
rcall updi_wait25ms
15
; Send LDS instruction:
16
rcall sendLds
17
; Read answer byte from Target UPDI:
18
[...]
Der Controller war direkt nach dem UPDI-Enable wohl einfach noch nicht bereit für den Speicherzugriff.
Auch die Chip-Erase-Prozedur funktioniert nun, nach dem Einfügen von 25-ms-Warteroutinen zwischen Issue_System_Reset und Clear_System_Reset, sowie in der sich anschließenden readLockStatus-Schleife.
Schade, dass diese Timing-Bedingungen nicht im Datenblatt erwähnt werden. Das hätte mir so einige Frustration erspart ...
Oh ja, ich erinnere mich: ich musste damals auch einige waits einbauen, 5 ms bspw., manchmal reichten schon 10 us.
Und jetzt ärgere ich mich, dass mir das nicht mehr einfiel und ich es nicht gleich vorschlagen konnte.
Danke :D Ich war aber auch ehrlich gesagt schon kurz vor dem Aufgeben. Der pymcuprog-Code liefert mir leider nicht wirklich neue Erkenntnisse, scheint auch einfach nur das zu machen, was ich schon tue …
Ich überlege auch hin und wieder, zu PIC-Controllern zu wechseln, in der Hoffnung, dass deren Programmier-Interface zuverlässiger bzw. einfacher zu handhaben ist als UPDI. Dafür müsste ich mich aber natürlich erstmal in PIC einarbeiten, da gibt es ja scheinbar größere Unterschiede zu AVR. Zu „In-Circuit Serial Programming“ habe ich anhand einer flüchtigen Google-Suche lediglich eine AppNote von 2003 gefunden, im Datenblatt des PIC16F1454 ist das ICSP nicht wirklich dokumentiert. Was die Frage aufwirft, ob die PIC-Programmier-Schnittstellen überhaupt öffentlich dokumentiert sind, also zum Selbst-Implementieren hinreichend, oder unter Verschluss gehalten, sodass man auf die käuflichen Programmer angewiesen wäre?
Sooo, das LDS-Problem ist gelöst. Ich habe nach dem updi_enable eine
Wartezeit von 25 ms eingefügt
Ganz so einfach war es doch nicht – ich hatte zunächst nur mit dem ATtiny416 getestet; als ich vorhin nochmal den 64DD28 ansteckte, wollte der mir nun partout wieder nicht auf die LDS-Anweisung antworten. Scheinbar will der wirklich unbedingt vorher noch den NVMProg-Key sehen, wie von Herrn Landolt vorgeschlagen. Also habe ich diese Passage (inkl. Reset vor- und nachher) wieder eingebaut. – Für den 64DD28 war das gut, der gab mir nun wieder die Signature Bytes heraus … Danach nochmal der Test mit dem tiny416 – und wieder Timeout, keine Antwort mehr auf LDS. –.–
Glücklicherweise haben tinyAVR 1-series und AVR-DD verschiedene NVM-Versionsziffern (0 bzw. 2), sodass man davon abhängig verschieden verfahren kann. Das habe ich nun in meinen Code eingebaut: vor dem LDS wird zunächst das SIB gelesen und nach der NVM-Version verzweigt; Version 0 bekommt einfach nur 25 ms Wartezeit, Version 2 dagegen erhält die komplette Reset–NVM-Key–Reset-Prozedur. So funktioniert es nun immerhin mit beiden AVR-Typen.
Nun mache ich mich an das Schreiben von Fuse Bytes. Das funktioniert bis jetzt nämlich noch nicht, seltsamerweise erhalte ich nach dem Senden des NVM-Prog-Keys einen ASI_KEY_STATUS von 0x00 – warum auch immer, vor dem LDS funktioniert es ja …
Ich überlege auch hin und wieder, zu PIC-Controllern zu wechseln, in der
Hoffnung, dass deren Programmier-Interface zuverlässiger bzw. einfacher
zu handhaben ist als UPDI. Dafür müsste ich mich aber natürlich erstmal
in PIC einarbeiten, da gibt es ja scheinbar größere Unterschiede zu AVR.
Zu „In-Circuit Serial Programming“ habe ich anhand einer flüchtigen
Google-Suche lediglich eine AppNote von 2003 gefunden, im Datenblatt des
PIC16F1454 ist das ICSP nicht wirklich dokumentiert. Was die Frage
aufwirft, ob die PIC-Programmier-Schnittstellen überhaupt öffentlich
dokumentiert sind, also zum Selbst-Implementieren hinreichend, oder
unter Verschluss gehalten, sodass man auf die käuflichen Programmer
angewiesen wäre?
Das Problem ist, dass es nicht "das ICSP" gibt. Hardwaretechnisch ist das ziemlich einheitlich. Clock, Data, GND, VTarget und ein MCLR/Reset, der aber auch höhere Spannungen erzeugen können muss (9V, 12.5V,...).
Das Protokoll ist jedoch unterschiedlich, abhängig davon ob Du einen 12 Bit, 14 Bit oder 16 Bit Core hast, oder PIC24/dsPIC, und bei PIC32 wird das MIPS EJTAG durchgetunnelt. Oftmals wird auch noch ein Programming Executive runtergeladen, der weitere Funktionen implementiert. Das alles zu implementieren macht irgendwie keinen Sinn, da kauft Du einen PICKIT5, der das alles plus PDI/UPDI/..., ARM SWD etc kann, und gut ist.
Es sei denn, Du hast kein wirkliches Leben und nichts andere zu tun. Aber das frage ich mich bei diesen Thread eh.
fchk
PS: Und debuggen kannst Du dann immer noch nicht. Bei Dir ist alles noch Fire and Forget. Auch unbefriedigend.
Das Protokoll ist jedoch unterschiedlich, abhängig davon ob Du einen 12
Bit, 14 Bit oder 16 Bit Core hast, oder PIC24/dsPIC, und bei PIC32 wird
das MIPS EJTAG durchgetunnelt. Oftmals wird auch noch ein Programming
Executive runtergeladen, der weitere Funktionen implementiert. Das alles
zu implementieren macht irgendwie keinen Sinn, da kauft Du einen
PICKIT5, der das alles plus PDI/UPDI/..., ARM SWD etc kann, und gut ist.
OK, danke für die Info. Das wäre mir dann auch zu kleinteilig/aufwendig.
Es sei denn, Du hast kein wirkliches Leben und nichts andere zu tun.
Aber das frage ich mich bei diesen Thread eh.
Tja, was ist „das wirkliche Leben“? Mir macht es halt Spaß, mich mit solchen Low-Level-Dingen und Assembler zu befassen. Dass das nicht jedermanns Sache ist, weiß ich. Andere gucken jeden Tag drei Stunden Fußball. So what.
Aber das hier ist ja ein Forum, also niemand muss jeden Thread lesen, der ihn nicht interessiert, … und es gibt hier mindestens einen, bei dem ich mir ziemlich sicher bin, dass er die Vorliebe für diese Thematik teilt und Interesse an meinen eventuellen Fortschritten hat.
PS: Und debuggen kannst Du dann immer noch nicht. Bei Dir ist alles noch
Fire and Forget. Auch unbefriedigend.
Was ich bis jetzt habe, ist natürlich nur ein „primitives“ Testprogramm für mich, um etwas mit UPDI herumzuspielen und zu sehen, inwieweit es mir möglich ist, dass vielleicht mehr daraus wird.
Davon abgesehen, an Debugging hat mir persönlich (bei meinen bisher noch sehr einfachen Assemblerprogrammen) UART-Ausgabe und Pin-Wackeln immer gereicht. Ich bin halt auch Hobbyist und kein Profi.
lass dich nicht entmutigen und dir den Spaß nicht nehmen. Solche Aussagen
Es sei denn, Du hast kein wirkliches Leben und nichts andere zu tun.
Aber das frage ich mich bei diesen Thread eh.
sind einfach nur dumm und unüberlegt. Wenn Frank AVR programmiert wird er sicherlich den avr-gcc und avrdude verwenden. Rate mal wieviel Leute daran arbeiten und ihre Freizeit dafür opfern. Einige davon sind hier im Forum dabei. Die fühlen sich bei solchen Aussagen bestimmt unwohl.
Also, ignorieren und weitermachen solange es Spass macht.
lass dich nicht entmutigen und dir den Spaß nicht nehmen.
Hallo, danke für die Bestätigung.
Nach langem letztlich erfolglosen Herumprobieren habe ich die Sache mit UPDI jetzt aber doch endgültig aufgegeben. Es ist für mich einfach nur ahnungsloses Stochern im Dunkeln; ich bekomme auf STS-Instruktionen keine 'ACK'-Antwort, auch wenn ich genauso vorgehe, wie mymcuprog es tut, und an allen möglichen Stellen Verzögerungen einbaue. Nun ist mir die Lust daran vergangen und ich werde mich anderen Dingen widmen, und irgendwann halt mal so ein PICKIT 5 kaufen.
... endgültig aufgegeben ... die Lust daran vergangen ...
Kann ich verstehen, kann ich sogar sehr gut verstehen - war schließlich auch einige Male soweit.
Nun aber würde mich Ihr derzeitiger Stand interessieren, rein für mich, wenn Sie also so gut sein würden und ihn hier einstellten, so wäre ich sehr verbunden.
"Man lernt an allem etwas", wie Gottfried Keller seinen grünen Heinrich sagen lässt.
Wenn Frank AVR programmiert wird
er sicherlich den avr-gcc und avrdude verwenden.
Wenn. Ich habe mich vor über 10 Jahren von AVR verabschiedet und zu PIC24, PIC32 und ARM gewechselt. Da habe ich fürs Geld einfach mehr Leistung und vor allem deutlich bessere Peripherie bekommen. Gut, die modern AVRs haben da inzwischen etwas aufgeholt, aber trotzdem. Und mehr als MPLABX, XC16/XC32 und ein PICKIT braucht man dafür nicht.
Und es ist ja nicht so, dass der TE damit etwas wirklich neues aufregendes erschaffen halt - es wurde nur versucht, bestehendes zu duplizieren.
Nun aber würde mich Ihr derzeitiger Stand interessieren, rein für
mich, wenn Sie also so gut sein würden und ihn hier einstellten, so wäre
ich sehr verbunden.
Bitteschön, angehängt ist der letzte, an den tiny1614 angepasste Stand. Der Code ist nicht schön, ich hätte ihn noch stark aufgeräumt, wenn sich Erfolg eingestellt und mich der Spaß daran nicht verlassen hätte.
Ich hatte versucht, auf dem 64DD28 die BOD-Fuse an Adresse 0x1051 mit dem Wert 0x10 (harmlose Änderung der Sample-Frequenz) zu schreiben. Schon beim ersten STS kam keine ACK zurück, obwohl vorher der NVM-Prog-Schlüssel erfolgreich erkannt wurde (NVMPROG in ASI_KEY_STATUS war 1, und PROGSTART in ASI_SYS_STATUS ebenso).
Ich habe mich vor über 10 Jahren von AVR verabschiedet und zu
PIC24, PIC32 und ARM gewechselt. Da habe ich fürs Geld einfach mehr
Leistung und vor allem deutlich bessere Peripherie bekommen.
Kann ich gut verstehen, ich habe auch öfters mal überlegt, zu PIC18 und höher zu wechseln.
Danke für die Vorbereitung des Programmes auf meinen ATtiny1614.
Erwarten Sie irgendwelche Kommentare von meiner Seite, oder haben Sie dieses Projekt endgültig ad acta gelegt?
Erwarten Sie irgendwelche Kommentare von meiner Seite, oder haben Sie
dieses Projekt endgültig ad acta gelegt?
Wenn Ihnen z.B. etwas Verdächtiges auffällt, dürfen Sie mir das gern mitteilen – ich würde mich schon freuen, wenn es vielleicht doch noch mal funktionieren sollte. Ich meinte nur, dass ich nicht weiter ohne konkrete Anhaltspunkte herumprobieren werde.
Okay, dann vorab nur soviel: Sie sind einem fatalen, wenngleich durchaus verständlichen Irrtum aufgesessen (war mir in der Anfangsphase auch mal passiert): Sie haben sozusagen den Zielcontroller aus den Augen verloren! Das /NVMCTRL_CMD_FUSEWRITE_gc/ ist das des ATtiny3216, für den AVR64DD28 ist es gar nicht definiert! Das 0x07 ist dort bestenfalls /reserved/, schlechtestenfalls hat es irgendeine üble Wirkung.
Alles Weitere, wenn ich mehr Zeit habe - vielleicht.
PS:
Und wenn ich mir die Bemerkung erlauben darf: Ihre Fixierung (um nicht zu sagen Obsession) auf die Fuses verstehe ich nicht - fangen Sie doch mit dem weniger kritischen EEPROM an, Fuses machen in der Anfangsphase nur Ärger.
Das NVMCTRL_CMD_FUSEWRITE_gc ist das des ATtiny3216, für den
AVR64DD28 ist es gar nicht definiert!
Ahja, danke für den Hinweis, ich hatte nur NVMCTRL_ADDR, NVMCTRL_DATA und NVMCTRL_CTRLA in den ...def.inc-Dateien verglichen (die übereinstimmen) und dann blind darauf vertraut, dass der Rest bei den NVM-Controllern auch gleich ist.
Aber müsste ich dann nicht dennoch wenigstens bei den ersten drei STS-Instruktionen, die ja nur in die o.g. NVM-Register schreiben, ACK-Antworten bekommen? Denn bereits daran ist es ja gescheitert.
Ihre Fixierung (um nicht
zu sagen Obsession) auf die Fuses verstehe ich nicht - fangen Sie doch
mit dem weniger kritischen EEPROM an, Fuses machen in der Anfangsphase
nur Ärger.
OK, die Fuses waren halt der Auslöser für meine Beschäftigung mit UPDI (weil das mEDBG ja daran bei dem AVR-DD versagt hat). Deshalb diese „Obsession“. :D
Aber OK, dann werde ich, falls es nochmal dazu kommt, mich am EEPROM zunächst versuchen.
Kann man mit dem mEDBG den ATtiny3216 auch debuggen, oder nur
programmieren?
Das weiß ich nicht, ich habe ehrlich gesagt noch nie Debugging per UPDI verwendet. Bei meinen bisherigen, noch ziemlich simplen Programmen reichte mir UART-Ausgabe und ggf. Pin-Wackeln fürs DSO.
Also wenn es nur um das ACK geht: fügen Sie einfach in §sendSts nach dem ersten 'rcall updi_tx' (an das ich mich nie gewöhnen werde) ein Warten mit 10 us ein.
PS:
dass der Rest bei den NVM-Controllern auch gleich ist
Die Mechanismen im NVM unterscheiden sich teilweise erheblich: megaAVR® 0-series, tinyAVR® n-series, AVRmxyn.
Also wenn es nur um das ACK geht: fügen Sie einfach in §sendSts nach dem
ersten 'rcall updi_tx' (an das ich mich nie gewöhnen werde) ein Warten
mit 10 us ein.
Also so wie folgt?
1
sendSts:
2
push [...]
3
; Wait for any previous transmission or reception to be completed:
4
sendSts_waitBusy:
5
sbrc updiFlags, UPDI_FLAGS_BUSY_bp
6
rjmp sendSts_waitBusy
7
; Send instruction code and address:
8
[...]
9
rcall updi_tx
10
rcall wait10us
11
; Wait for first 'ACK' from Target UPDI:
12
sendSts_wait0:
13
sbrc updiFlags, UPDI_FLAGS_TIMEOUT_bp
14
rjmp sendSts_timeout
15
sbrs updiFlags, UPDI_FLAGS_RXC_bp
16
rjmp sendSts_wait0
17
; updiUartData_ram now contains the received byte.
18
lds tmp0, updiUartDataBuf_ram
19
cpi tmp0, UPDI_ACK
20
brne sendSts_invAnswer
21
; Send data byte:
22
[...]
23
rcall updi_tx
24
; Wait for second 'ACK' from Target UPDI:
25
sendSts_wait1:
26
[...]
Ohne es ausprobiert zu haben: Wie könnte das denn etwas ändern – nach dem Aufruf von updi_tx wird ja ohnehin nur gewartet, nämlich bis das RXC-(oder Timeout-)Flag von der Timer-ISR gesetzt wird? Da würde es doch nichts ausmachen, wenn die Flag-Warteschleife erst 10 µs später beginnt. Oder habe ich etwas falsch verstanden?
'rcall updi_tx' (an das ich mich nie gewöhnen werde)
Da würde ich jetzt aber gern genauer wissen, was der Grund dafür ist. ;)
Kritisieren Sie ruhig, wenn an der Subroutine oder der Struktur meines Programmes im Allgemeinen etwas mangelhaft ist. Ich bin immer noch ein Anfänger in Assembler und Programmierung im Allgemeinen und lerne immer gerne dazu. Das Programm ist in seiner Gestaltung halt meinem bisherigen (Un-)Wissensstand geschuldet. Also ich freue mich wirklich jederzeit sehr über jegliche konstruktive Kritik und Verbesserungsvorschläge, die mich weiterbringen.
Es ist einfach nur ungewohnt, und erscheint mir unnötig kompliziert. Mag daran liegen, dass ich schon immer für UPDI-Kommunikation einen Hardware-USART verwendete, und ein Byte immer gleich dann ausgab, wenn es zur Verfügung stand.
Zum Wait: ich hatte heute morgen lediglich meine Hilfsausgabe an dieser Stelle eingebaut, und dann lief es. Danach hatte ich die Hilfsausgabe durch ein wait10us ersetzt, und es lief noch immer durch, wenn auch mit unsinnigem Resultat.
Und jetzt muss ich mich erstmal von der Bergtour erholen - später melde ich mich vielleicht noch mal.
Es ist einfach nur ungewohnt, und erscheint mir unnötig kompliziert. Mag
daran liegen, dass ich schon immer für UPDI-Kommunikation einen
Hardware-USART verwendete, und ein Byte immer gleich dann ausgab, wenn
es zur Verfügung stand.
Hmm OK, sicher ist das alles durch den Software-UART noch komplizierter als nötig. Ich werde diese Angelegenheit also erstmal ruhen lassen, bis ich einen Controller mit zwei USARTs auf einer Experimentierplatine untergebracht habe. Bis dahin werde ich mich jetzt erst einmal mit dem „guten alten“ ISP beschäftigen (da ich noch eine größere Zahl älterer AVRs besitze und mir gerne dafür weitere Programmer – neben dem einen kommerziellen, den ich habe – anfertigen möchte).
Da haben Sie wohl etwas missverstanden im Bereich NVM:
Mit diesen Korrekturen kann ich, von meinem ATtiny1614 aus, das EEPROM meines AVR16DD28 schreiben (und lesen; 1400..14FF). Es sieht etwas unordentlich aus, meiner derzeitigen Verfassung geschuldet, aber Sie kommen sicher zurecht. Ob damit auch die Fuses erreichbar sind, überlasse ich Ihnen.
So Sie denn überhaupt noch wollen und nicht schon bei den älteren AVR8 mit dem SPI-Programming sind.
Hier noch, wie der entsprechende Programmteil bei mir aussieht
Vielen Dank, bin gerade dabei, mein Programm zu korrigieren und 'Fuse' durch 'EEPROM' zu ersetzen. Mal sehen, ob sich dann etwas tut ...
Nachtrag 19:17 Uhr: Nach dem Einfügen der 1-ms-Wartezeit vor dem Senden der zweiten STS-Hälfte bekomme ich nun die ACK-Antworten und das Schreiben des EEPROM-Bytes (0x1400, Wert 0x55) scheint zunächst erfolgreich gewesen zu sein.
Wenn ich danach per LDS die Adresse 0x1400 lese, erhalte ich jedoch immer noch 0xFF zurück, wie vorher, und nicht 0x55 ...
Das Register NVMCTRL_STATUS enthält nach dem Schreibversuch 0x10, also Error Code 'Invalid Command'. Bleibt nun noch herauszufinden, woran das nun wieder liegt ...
Vielen Dank schonmal, ich schaue es mir an und vergleiche ...
Nachtrag: habe jetzt noch die 25-ms-Wartezeiten zwischen den STS-Befehlen eingefügt (statt 5 ms, das dürfte ja unkritisch sein). Gleiches Ergebnis: ASI_SYS_STATUS == 0x10 --> "Invalid Command". Den relevanten Code-Ausschnitt habe ich angehängt. Da muss irgendwo noch ein Fehler sein ...
Nachtrag 2: Ich glaube, ich habe den Fehler gefunden, und zwar in der STS-Routine ... melde mich gleich wieder.
Die Fehler in der STS-Routine (irrige push/pop-Verwendung) und auch in der 'loop_writeEeprom'-Sequenz (versehentlich 'lds' statt 'ldi' – Copy-and-Paste-Leichen) sind nun beseitigt. Habe auch noch mal mit Ihrer main.asm verglichen. Dennoch bekomme ich am Ende NVMCTRL_STATUS == 0x10, und der Schreibversuch war ohne Effekt:
1
Sending STS ...
2
04:55 44 00 10
3
02:55 13
4
OK
5
Sending STS ...
6
04:55 44 00 14
7
02:55 AB
8
OK
9
Waiting while NVMCTRL is busy ...
10
04:55 04 02 10
11
NVMCTRL_STATUS: 10
12
Issuing System Reset ...
In 'updi_tx' habe ich noch zur Kontrolle die Bytes ausgeben lassen, die gesendet werden (Anzahl_Bytes_hex:Byte0_hex Byte1_hex ...). Nach meinem Ermessen stimmen die – ich weiß mir nun wieder mal keinen Rat, was nun das Problem ist.
Ermessen stimmen die – ich weiß mir nun wieder mal keinen Rat, was nun
das Problem ist.
Ein PICKIT5 zu kaufen, per MPLABX IPE das EEPROM zu programmieren und dabei mit einem Logic Analyzer mitzuprotokollieren, was da auf der Leitung passiert, ist wohl zu einfach, oder?
Warum nur, bitte, bauen Sie mitten in STS ein SYNCH ein, im Widerspruch zum Datenblatt (und Ihren früheren Versionen)?:
1
Sending STS ...
2
04:55 44 00 10
3
02:55 13
Werfen Sie das raus:
1
brne updi_sts_invAnswer
2
; Got first ACK. Send data byte:
3
rcall wait1ms
4
sts updiUartDataCount_ram, zero
5
ldi tmp0, UPDI_SYNCH
6
; rcall updi_appendBuf ; <=== SLdt 2406251318
7
mov tmp0, tmp2 ; Data byte to be written.
1
Sending STS ...
2
04:55 44 00 10
3
01:13
und schon funktioniert es.
Ich meine, im früheren /sendSts/ stand doch auch nur:
1
; Send data byte:
2
sts updiUartDataBuf_ram, tmp2 ; Data byte to be written.
3
ldi tmp3, 1
4
sts updiUartDataCount_ram, tmp3 ; Transfer block size.
5
rcall updi_tx
Sie kennen Reinhard Meys 'Annabelle'?
PS:
Dennoch bekomme ich am Ende NVMCTRL_STATUS == 0x10
Ja, genau: 'INVALIDCMD The selected command is not supported' - seien Sie froh, dass im AVR64DD28-Datenblatt unter NVMCTRL.CTRLA.CMD nicht steht: '0x55 CONTFIRE set the controller on fire'.
Warum nur, bitte, bauen Sie mitten in STS ein SYNCH ein, im Widerspruch
zum Datenblatt (und Ihren früheren Versionen)?
Das wird schludriges Copy&Paste von mir gewesen sein, anders kann ich es mir nicht erklären. Und ich hatte Tomaten auf den Augen, dass ich das nicht an der UART-Ausgabe der Befehle bemerkte. Ich bitte vielmals inständigst um Verzeihung.
Dann können Sie jetzt ja endlich die Fuses schreiben - also bei mir funktioniert das.
Trotzdem wäre ich damit vorsichtig: schnell ist versehentlich SYSCFG0 erwischt, mit einem unglücklichen Wert.
Dann können Sie jetzt ja endlich die Fuses schreiben
Ja, das habe ich noch vor zu testen. Werde auch vorsichtig sein.
Im Moment bin ich aber noch dabei, mit meinem zum UPDI-Sniffer abgespeckten Programm den Datenverkehr mitzulesen, den mein mEDBG beim (erfolgreichen) Lesen der Signature Bytes meines ATtiny416 erzeugt – letzterer weigert sich nämlich (seit einem vermutlich gescheiterten Chip Erase), auf jene LDS-Anfragen meines Programmes zu antworten, im Gegensatz zum 64DD28. In der Hoffnung, das dies mir Erleuchtung darüber verschafft, was der mEDBG anders macht als ich ...
Nachtrag: Es funktioniert leider so einfach nicht, wie ich naiverweise dachte. Da müsste ich mehr Aufwand treiben, auf den ich aber gerade keine Lust habe (um den UART-Rx bitsynchron zu bekommen). Ich schaue mir stattdessen noch mal den mymcuprog-Quelltext an ...
NVMCTRL.CTRLA.CMD ist beim ATtiny416 nur von 0 bis 7 definiert.
Ja, diese Passage muss ich noch aktualisieren bzw. MCU-spezifisch machen. Habe STS auch, seit ich weiß, dass die NVM-Controller unterschiedlich sind, nicht mehr beim ATtiny416 verwendet.
sowie noch die darauffolgende Sequenz wie folgt geändert
Das ist vermutlich der Fehler - ich hatte nur das /breq/ auskommentiert und konnte anschließend auf meinem ATtiny412 das EEPROM lesen.
Allerdings fürchte ich, wir kommen auf diese Art auf keinen grünen Zweig. Sie "stochern herum", um Ihren eigenen Ausdruck zu gebrauchen, und ich übe mich zwar in der Fehlersuche fremder Programme, habe aber eigentlich mit den eigenen genug zu tun.
Also ich habe nun den Zustand von vorher wiederhergestellt, bis auf das auskommentierte 'breq', und immer noch funktioniert es nicht. Es muss einen Unterschied zwischen meinem tn416 und Ihrem tn412 hinsichtlich des Verhaltens bei LDS-Instruktionen geben. So wie es offenbar einen Unterschied zwischen meinem tn416 und dem 64DD28 gibt – der antwortet mir nämlich brav auf die LDS ausgehend von demselben Code. Warum das so ist, kann ich mir einfach nicht erklären. Früher hat ja mein Code auch mal mit dem(selben) ATtiny416 funktioniert.
Überhaupt finde ich es seltsam, dass der AVR64DD28 scheinbar den NVM-Prog-Key sehen will, bevor er eine LDS-Instruktion akzeptiert (ohne diesen tut er bei mir nichts). Das wird doch im Datenblatt so nicht gefordert, wenn man nur per LDS lesen, nicht schreiben will?
Asche auf mein Haupt, ich hatte wohl doch irgendeine Kleinigkeit anders als vorher – gerade nochmal mein letztes ZIP heruntergeladen und die fragliche Passage von dort kopiert – nun funktioniert es:
1
Address: 1100
2
02:55 E5
3
NVM version number: 0
4
03:55 C8 59
5
03:55 C8 00
6
0A:55 E0 20 67 6F 72 50 4D 56 4E
7
03:55 C8 59
8
03:55 C8 00
9
04:55 04 00 11
10
LDS returned 1E
Vielen Dank nochmals für Ihre beständige und geduldige Hilfe ... ich muss mir angewöhnen, in manchen Belangen sorgfältiger zu arbeiten; es schleichen sich immer wieder Schludrigkeitsfehler durch Unachtsamkeit bei mir ein. Daran muss ich arbeiten ...
Das probeweise Schreiben der BOD-Fuse auf den Wert 0x10 (Änderung der Sample-Frequenz) auf dem AVR64DD28 hat nun auch funktioniert. Damit ist bewiesen, dass der 64DD28 intakt ist, und dass der Fehler somit beim mEDBG bzw. dem Programming Tool vom Microchip Studio liegt. Das ist nun auch mein Fazit aus diesem Thread.
Das MPLAB IPE v6.20 habe ich übrigens mittlerweile auch probiert; dieses verweigert aber von vornherein die Benutzung des mEDBG mit dem AVR64DD28 (und auch dem ATtiny3216, also wahrscheinlich mit allem außer dem auf dem Xplained Nano Board befindlichen ATtiny416).
Ungeklärt ist noch, warum auch 'pymcuprog' bei mir mit der Fehlermeldung "UPDI initialization failed" versagt (sowohl beim 64DD28 als auch beim tiny416). Zumindest blinken kurz die Rx- und Tx-LEDs meines MCP2221-USB-UART-Adapters, also war zumindest das korrekte Port ausgewählt. Vermutlich liegt das Problem irgendwo bei meinem Python-Toolchain-Setup, aber das ist wieder ein anderes Thema.
Ich werde nun dazu übergehen, den Weg von SerialUPDI zu beschreiten, d.h. ein PC-Programm entwickeln, das mit dem Ziel-AVR über eine virtuelle COM-Schnittstelle und einen USB-UART-Adapter kommuniziert.
avr64dd28-device-info.png
(32 KB)
avr64dd28-fuses-gelesen.png
(41 KB)
avr64dd28-error.png
(12 KB)
avr-db28-dd28-board-sch.png
(58 KB)
