Hallo,
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 ...
Grüße
Johannes
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.
S. L. schrieb:> 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.
Johannes T. F. schrieb:> ein ATtiny416 Xplained Nano mit mEDBG
Wurde das Tool schon an anderen (kleineren) Targets erprobt?
Johannes T. F. schrieb:> ...wird das Device auch korrekt erkannt
Woher kommt der rote Rahmen? Das ist ein Diskrepanz-Hinweis.
Georg M. schrieb:> Johannes T. F. schrieb:>> ein ATtiny416 Xplained Nano mit mEDBG>> Wurde das Tool schon an anderen (kleineren) Targets erprobt?
Ja, ich habe es bisher an verschiedenen 1-series-ATtinys erfolgreich
verwendet (z.B. 3216, 412).
Georg M. schrieb:> 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.
Hallo,
Ist bestimmt die alte Firmware die auf der Platte liegt. Aktuelle gibt
es hier.
https://packs.download.microchip.com/
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.
Veit D. schrieb:> Laut älteren Thread soll das Pkob Nano Pack das Passende sein.
Dieses enthält allerdings nur "*n*edbg_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 …
Trotzdem danke für den Tipp.
Hallo,
du hast den ATTINY416 XPLAINED NANO als Programmer, der ist natürlich
medbg.
https://packs.download.microchip.com/
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)
b) mit dem Tool atfw.exe
So ein Forum ist gleichzeitig Backup, man muss sich nur erinnern können.
:-) :-) :-)
Beitrag "Re: ATmega 4809 Curiosity Nano - Firmware Update klappt nicht"
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.
Veit D. schrieb:> 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.
Veit D. schrieb:> 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.
Hallo,
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.
Veit D. schrieb:> woher sind deine Dupont Kabel?
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.
Hallo,
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.
Veit D. schrieb:> Du könntest probieren> eine harmlose Fuse zu ändern. Um zu sehen ob der Fuse Schreibvorgang> auch fehlschlägt.
Ja, ich habe mehrfach versucht, allein das BOD-Level zu ändern, ohne
Erfolg.
Veit D. schrieb:> 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?
Hallo,
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.
Veit D. schrieb:> 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 …
Timo S. schrieb:> 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.
Veit D. schrieb:> In der device_support.xml der medbg Firmware sind die AVRxDD Typen> gelistet.
Ich würde nicht alles glauben, was diese Verfasser herausgeben.
Moin,
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.
Grüße!
Micha W. schrieb:> die Hide-Option hast du auf false gesetzt?
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.
Hallo,
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.
Hallo,
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.
S. L. schrieb:> 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.
S. L. schrieb:> Lässt sich die IDE zwingen, den 'DD' als 'DA' oder 'DB' zu behandeln?
Hmm, weiß nicht ...
Veit D. schrieb:> 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.
Veit D. schrieb:> Du> kannst mit dem mEDBG ATtinys flashen aber keine AVR Typen?
Ja genau. Zumindest scheinbar keine AVR64DD...
Veit D. schrieb:> Welche AVR> Typen hast du probiert?
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.
Veit D. schrieb:> Probiere auf jeden Fall nochmal einen> unabhängigen Programmer, den besagten pyupdi, Stichwort pymcuprog.
Ja, werde ich demnächst tun; mal sehen, wann ich dazu komme.
Veit D. schrieb:> Am Schaltplan kann ich keine Fehler sehen, diesbezüglich schon gar> nicht.
Vielen Dank nochmal für’s drüber schauen.
> ... wenn nichtmal die Fuses gesetzt werden können
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'.
S. L. schrieb:> 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.
Schade; vielleicht sagt die Fehlermeldung Veit Devil etwas. Was mich
betrifft, so muss ich nun endgültig passen.
PS:
Mit Ihrem Programm lässt mein AVR32DD14 eine LED blinken, mit ca. 220
ms.
PPS:
Noch etwas zur Aufheiterung (Ähnlichkeiten mit einer gewissen IDE wären
rein zufällig).
Veit D. schrieb:> 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.
Johannes T. F. schrieb:> (...) 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
Grüßle,
Volker
Veit D. schrieb:> Ganz doof gefragt, Du hast nicht Ausversehen UPDI per Fuse disabled?
Nein, ich bin wirklich nur an die BOD-Fuses ran gegangen, alles andere
habe ich nicht berührt. Und die DDs kamen frisch von Mouser.
Veit D. schrieb:> 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.
Volker B. schrieb:>> (...) 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?
Hallo,
für pyupdi hast du auch alles Notwendige
> pip install pymcuprog> pip install pip> pip install intelhex> pip install pylint> pip install pyserial (Nicht 'serial'!)
installiert?
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.
S. L. schrieb:> ... was hat sich Microchip bei "Value 0: GPIO UPDI pin is configured> as GPIO" bloß gedacht?
Das ist in der Tat unlogisch ausgerechnet dafür Default '1' zu wählen.
Wir hoffen das Beste für den TO. Hat zur Zeit zu viele Baustellen
gleichzeitig.
> Das ist in der Tat unlogisch
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.
Veit D. schrieb:> 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:
Veit D. schrieb:> Masseverbindungen vorhanden? Problem mit 3,3V <> 5V?
Massen sind verbunden, USB-UART und ATtiny3216 hängen an den +5V aus
demselben 7805, daran kann es also nicht liegen.
Veit D. schrieb:> 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.
Hallo,
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 …
[1]
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATtiny212-214-412-414-416-DataSheet-DS40002287A.pdf
> Nun möchte ich im nächsten Schritt die Fuses des Ziel-AVRs lesen
Die Fuses stehen ab 0x1050 im Data-space und werden mit dem UPDI-Befehl
LDS gelesen.
(Bei den ATtinys (und z.B. dem ATmega4809) ab 0x1280)
PS:
> an anderen Stellen werden nur Offsets für die Fuse-Bytes angegeben
Mais non - z.B. AVR32DD28def.inc:
Vielen Dank für die schnelle Antwort.
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.
Hallo,
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 …
Hallo,
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.
Veit D. schrieb:> Kannst du das Lock-Key Register im gesperrten Zustand auslesen?
Laut Datenblatt des AVR64DD28, S. 58 (s. Anhang): nein.
Veit D. schrieb:> 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 …
> ... Oder man das selbst machen muss.
Wie sollte das gehen? Der Controller wäre ja noch immer gesperrt,
folglich hätte UPDI keinen Zugriff auf die Lock-Bytes.
S. L. schrieb:>> ... Oder man das selbst machen muss.>> 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.
S. L. schrieb:> Ich halte es eher für den üblichen Sprachgebrauch, siehe das 'cleared'> im Anhang. Im Gegensatz zu 'Lock set'.
OK, danke für die Info – dann wird es wohl so sein, dass in LOCK.KEY
nach dem Chip Erase der Entsperr-Schlüssel geschrieben wird. Ergibt ja
auch Sinn.
Hallo,
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".
> ... Basis-Adresse der UPDI-Register ...
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.
Hallo nochmal an alle,
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.
fchk
Frank K. schrieb:> In Deinem Fall wäre das ein PICKIT 5 mit MPLABX.
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 ...
Johannes T. F. schrieb:> 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.
an Johannes T. Fechner:
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.
S. L. schrieb:> 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.
an Johannes T. Fechner:
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.
S. L. schrieb:> 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 ...
S. L. schrieb:> ich arbeite dran, ich arbeite dran ...
Vielen vielen Dank noch einmal für Ihre Mühe!
Adam P. schrieb:> Nutzt du jedoch die JLink.exe oder atprogram.exe und setzt die Fuses per> Befehl direkt über die Konsole, dann funktioniert es.
Habe gerade mal versucht, atprogram.exe direkt aufzurufen – auch hierbei
trat der Fehler auf:
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.
S. L. schrieb:> rcall updi_enable> rcall systemReset ; <=============== SLdt 2406201909> ; Send LDS instruction:
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.
S. L. schrieb:> Probieren Sie Folgendes in main.asm:
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!
S. L. schrieb:>> an einem AVR128DB28 getestet> Bei meinem geht es, Date-code 2037K94; welchen hat Ihrer?
Meiner hat den Code 2242WVR.
S. L. schrieb:> Also gut, nächster Versuch:
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.
> Allerdings bekomme ich ebenfalls bei der ChipErase-Sequenz ein Timeout.
Okay, kommt bei mir auch, siehe Anhang, und ist erstmal zwar hässlich,
trotzdem wirkungsvoll - bei Ihnen nicht?
PS:
Andererseits: warum sollte Ihr ATtiny416 überhaupt gesperrt sein?
PPS:
> ATtiny416 gar nicht, da kommt nie eine Antwort
Auch nicht bei '(1) Read SIB'?
Dann wäre vermutlich SYSCFG0.RSTPINCFG[1:0] gesetzt, und es hülfe nur
ein HV-Reset.
S. L. schrieb:> Okay, kommt bei mir auch, siehe Anhang, und ist erstmal zwar hässlich,> trotzdem wirkungsvoll - bei Ihnen nicht?
Leider nicht, auch nach dem Menüpunkt ChipErase kommt bei mir nur
"Timeout" beim Versuch, die Signature-Bytes auszulesen.
S. L. schrieb:> 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.
S. L. schrieb:> Auch nicht bei '(1) Read SIB'?
Doch, das Lesen des SIB klappt bei mir immer.
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 ...
S. L. schrieb:> 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.
S. L. schrieb:> 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:
Habe diese kurz überflogen und denke, dass ich dort finde, was ich
brauche.
S. L. schrieb:> 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 ...
> ... Wartezeit ...
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.
Veit D. schrieb:> du hast meinen vollen Respekt!
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?
Johannes T. F. schrieb:> 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 …
Johannes T. F. schrieb:> 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.
Frank K. schrieb:> 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.
Frank K. schrieb:> 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.
Frank K. schrieb:> 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.
Hallo,
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.
Veit D. schrieb:> 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.
PS:
> STS-Instruktionen keine 'ACK'-Antwort
Mit welchen Adressen haben Sie es versucht?
Veit D. schrieb:> 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.
fchk
S. L. schrieb:> 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.
S. L. schrieb:> Mit welchen Adressen haben Sie es versucht?
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).
Frank K. schrieb:> 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.
Frank K. schrieb:> Und es ist ja nicht so, dass der TE damit etwas wirklich neues> aufregendes erschaffen halt
Das ist mir klar, siehe oben. seufzFrank K. schrieb:> es wurde nur versucht, bestehendes zu> duplizieren.
Mitnichten – es wurde versucht, Freude am Hobby und Erfolgserlebnisse zu
haben und dabei meine Programmierkenntnisse auszubauen ...
an Johannes T. Fechner:
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?
S. L. schrieb:> 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.
Johannes T. F. schrieb:> Ja, ich habe es bisher an verschiedenen 1-series-ATtinys erfolgreich> verwendet (z.B. 3216, 412).
Kann man mit dem mEDBG den ATtiny3216 auch debuggen, oder nur
programmieren?
S. L. schrieb:> 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.
S. L. schrieb:> 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.
Georg M. schrieb:> 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.
> ACK-Antworten bekommen
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.
S. L. schrieb:> 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?
S. L. schrieb:> '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.
S. L. schrieb:> 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).
S. L. schrieb:> Und jetzt muss ich mich erstmal von der Bergtour erholen - später> melde ich mich vielleicht noch mal.
Ja dann, gute Erholung, und hoffentlich bis später!
Johannes T. F. schrieb:> Das weiß ich nicht, ich habe ehrlich gesagt noch nie Debugging per UPDI> verwendet.
Einfach in den Speicher schauen. Beim ATtiny1614 funktioniert es mit dem
mEDBG.
(Beim ATtiny824 schon nicht mehr - nur programmieren)
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 - nur
damit Sie einen rein optischen Eindruck bekommen.
Bei Ihnen ist das abschließende NO CMD offenbar nicht nötig, vermutlich
wegen des Nachlaufs in Ihrem Programm.
S. L. schrieb:> Da haben Sie wohl etwas missverstanden im Bereich NVM:
Ohja, habe gerade nochmal ins Datenblatt geschaut ...
S. L. schrieb:> 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 ...
> Bleibt nun noch herauszufinden ...
Stellen Sie das aktuelle main.asm hier ein, zum Vergleichen wird's bei
mir gerade noch reichen.
Bei mir funktioniert es:
Pardon, also das dauert mir jetzt zu lange. Im Anhang das main.asm, wie
es bei mir läuft - wait1ms und wait5ms müssen Sie sich selbst
dazustricken.
Im übrigen ist es vermutlich mein Fehler, wahrscheinlich hatte ich nicht
alle Korrekturen mitgeteilt.
S. L. schrieb:> Pardon, also das dauert mir jetzt zu lange.
Sorry, ich war noch damit beschäftigt, meinen Code etwas aufzuräumen,
damit ich und evtl. auch Sie besser durchblicken.
S. L. schrieb:> Im Anhang das main.asm,
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.
Anbei noch der aktuelle Stand meines Quellcodes.
Ich habe ihn etwas aufgeräumt und auf mehr Dateien verteilt, um die
Handhabung zu vereinfachen.
Werde dann erst heute Nachmittag voraussichtlich ab 15 Uhr wieder Zeit
haben, um weiterzumachen.
Grüße
Johannes
Johannes T. F. schrieb:> 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?
fchk
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'.
S. L. schrieb:> 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.
S. L. schrieb:> seien> Sie froh, dass im AVR64DD28-Datenblatt unter NVMCTRL.CTRLA.CMD nicht> steht: '0x55 CONTFIRE set the controller on fire'.
Wie gut, dass ich hier einen Feuerlöscher in der Nähe habe ...
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.
S. L. schrieb:> 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 ...
> STS dann noch nicht läuft auf dem ATtiny
Warum dieses?:
1
; Hold target device in reset:
2
rcall updi_applyReset
Mit einem anschließenden 'rcall updi_releaseReset' (und passenden waits)
ist 'ASI KEY STATUS: 10'.
Dass dann noch immer nicht geschrieben wird, ist auch klar:
1
; EEERWR - EEPROM Erase and Write Enable:
2
ldi tmp0, low(NVMCTRL_CTRLA)
3
ldi tmp1, high(NVMCTRL_CTRLA)
4
ldi tmp2, 0x13
NVMCTRL.CTRLA.CMD ist beim ATtiny416 nur von 0 bis 7 definiert.
S. L. schrieb:> Warum dieses?:> ; Hold target device in reset:> rcall updi_applyReset
Das habe ich von 'pymcuprog' abgeguckt, ich zitiere aus
pymcuprog/serialupdi/application.py:
Ich hatte mich zwar ob des "Hold in reset" auch gewundert, dachte aber,
„die werden es schon wissen.“
S. L. schrieb:> 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.
S. L. schrieb:>> ATtiny416 ... weigert sich ... auf jene LDS-Anfragen ...>> im Gegensatz zum 64DD28.>> Na, dreimal dürfen Sie raten ...
Ich habe gemäß Ihrem Vorschlag das betreffende 'breq' auskommentiert,
sowie noch die darauffolgende Sequenz wie folgt geändert:
1
rcall updi_applyReset
2
rcall wait5ms
3
rcall updi_releaseReset
4
rcall wait5ms
5
rcall updi_enterNvmProgKey
6
rcall wait5ms
7
rcall updi_applyReset
8
rcall wait5ms
9
rcall updi_releaseReset
10
rcall wait5ms
11
rjmp loop_readByte_lds ; updi_lds folgt.
Trotzdem antwortet mein ATtiny416 nicht:
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
11
Error: Timeout while waiting for UPDI answer.
Er ist aber nicht defekt – mit dem mEDBG findet die Kommunikation
problemlos statt.
> 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.
S. L. schrieb:> Das ist vermutlich der Fehler
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?
> Also ich habe nun den Zustand von vorher wiederhergestellt, bis auf ...
Sicher? Zeigen! main.asm als Anhang.
> wenn man nur per LDS lesen ... will
Dazu kann ich nur sagen, dass ich darüber auch gestolpert war, vor
langer Zeit, damals war der AVR128DA28 gerade herausgekommen.
S. L. schrieb:> Sicher? Zeigen! main.asm als Anhang.
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.
Thread beobachten
Seitenaufteilung abschalten