AVR64DD28, mEDBG, Studio 7.0 - Fehler beim Schreiben von Fuses

[Johannes T. F. (jofe)]

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

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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.

[Georg M. (g_m)]

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.

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

Hallo,

Ich habe den leisen Verdacht dass die Programmer Firmware zu alt ist.

[Johannes T. F. (jofe)]

Veit D. schrieb:
> 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.

[1] https://www.microchip.com/en-us/development-tool/attiny416-xnano
[2] 
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/UserGuides/ATtiny416-Xpl-Nano-EV-Kit-Users-Guide-DS50002683B.pdf

=====
Nachtrag: ich fand gerade einen Hinweis auf die 
Firmware-Update-Möglichkeit auf einer Seite zu einem ähnlichen Board:
https://onlinedocs.microchip.com/pr/GUID-FC2A0384-AC9D-45B4-951E-5C0DEFE8B2E9-en-US-5/index.html?GUID-E45ECAF4-48D5-4D67-BE87-4DF8AE01358D

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 …

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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?

[Veit D. (devil-elec)]

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.

[Timo S. (kaffeetas)]

Funktioniert irgend ein anderes Kommando z.B. Flash auslesen oder chip 
erase?

[Johannes T. F. (jofe)]

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.

[Georg M. (g_m)]

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.

[Micha W. (blackxiiv)]

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!

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

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.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

> ... 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'.

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

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).

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

Hallo,

Aufheiterung ist immer gut. Danke.

Habe soeben meinen AVR64EA32 mit pyupdi probiert, funktioniert.

pymcuprog.exe write -d avr64ea32 -t uart -u com8 -f blink.hex --erase --verify

Connecting to SerialUPDI
Pinging device...
Ping response: 1E961F
Erasing device before writing from hex file...
Writing from hex file...
Writing flash...
Verifying flash...
OK
Done.

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.

[Volker B. (Firma: L-E-A) (vobs)]

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

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

> 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?

[Veit D. (devil-elec)]

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.

[S. L. (sldt)]

> 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.

[Johannes T. F. (jofe)]

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:

./pymcuprog ping -t uart -u /dev/ttyACM0 -d attiny3216
Connecting to SerialUPDI
pymcuprog.pymcuprog - ERROR - Operation failed with PymcuprogSerialUpdiError: UPDI initialisation failed

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.

[Johannes T. F. (jofe)]

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

[S. L. (sldt)]

> 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:

;*************************************************************************
;** FUSE - Fuses
;*************************************************************************

.equ FUSE_WDTCFG = 0x1050                ; Watchdog Configuration
.equ FUSE_BODCFG = 0x1051                ; BOD Configuration
.equ FUSE_OSCCFG = 0x1052                ; Oscillator Configuration
.equ FUSE_SYSCFG0 = 0x1055               ; System Configuration 0
.equ FUSE_SYSCFG1 = 0x1056               ; System Configuration 1
.equ FUSE_CODESIZE = 0x1057              ; Code Section Size
.equ FUSE_BOOTSIZE = 0x1058              ; Boot Section Size

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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 …

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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 …

[S. L. (sldt)]

> ... 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.

[Johannes T. F. (jofe)]

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. (sldt)]

> Formulierungsfehler

Ich halte es eher für den üblichen Sprachgebrauch, siehe das 'cleared' 
im Anhang. Im Gegensatz zu 'Lock set'.

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

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'

[Johannes T. F. (jofe)]

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".

[S. L. (sldt)]

> ... 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.

[Johannes T. F. (jofe)]

S. L. schrieb:
> Gibt es nicht, bzw. ist 0.

Aha, super, vielen Dank für die schnelle Antwort!

[Johannes T. F. (jofe)]

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

AVR     P:2D:1-3

vom AVR64DD28 und

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.

[Johannes T. F. (jofe)]

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. :(

[Frank K. (fchk)]

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

[Johannes T. F. (jofe)]

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 ...

[Adam P. (adamap)]

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.

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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.

[Georg M. (g_m)]

Ich habe jetzt festgestellt:
weder AVR16DD14 noch AVR16EB14 wollen mit dem mEDBG programmiert werden.

Es ist Zeit für einen nEDBG.

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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

.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.

[S. L. (sldt)]

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.

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

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 ...

[Johannes T. F. (jofe)]

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:

C:\Program Files (x86)\Atmel\Studio\7.0\atbackend>atprogram -t medbg -i updi -d avr128db28 write -fs -o 0x1051 --values E0 --verify
Firmware check OK
[ERROR] An error occurred executing a command (write): Verification of write failed. Memory could not be read.

Nachtrag: Nun noch einmal einen Chiperase scheinbar erfolgreich 
durchgeführt,

C:\Program Files (x86)\Atmel\Studio\7.0\atbackend>atprogram -t medbg -i updi -d avr128db28 chiperase
Firmware check OK
Chiperase completed successfully

und danach noch einmal o.g. Kommando ausgeführt: es erscheint wieder 
dieselbe Fehlermeldung.

[S. L. (sldt)]

Probieren Sie Folgendes in main.asm:

loop_readByte:
...
...
; Enable Target UPDI:
  rcall  updi_enable

rcall systemReset  ; <=============== SLdt 2406201909

; Send LDS instruction:
  rcall  sendLds
...

[S. L. (sldt)]

Address: 1080 Data: 1E
Address: 1081 Data: 94
Address: 1082 Data: 3F
Und der geneigte Leser erkennt einen AVR16EB28.

Address: 1100 Data: 1E
Address: 1101 Data: 92
Address: 1102 Data: 23
Das war ein ATtiny412.

Address: 1100
Error: Timeout while waiting for UPDI answer.
Und der Landolt blicket stumm
auf dem ganzen Tisch herum.
Bzw. auf den fabrikneuen AVR16DD28.

Dabei bringt dieser bei '1' "AVR     P:2D:1-3"

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.

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

> bei keinem meiner Versuche eine Antwort vom AVR128DB28.
Aha, interessant; ein älterer zeigt bei mir:

AVR     P:2D:1-3
Address: 1100 Data: 1E
Address: 1101 Data: 97
Address: 1102 Data: 0E

[Johannes T. F. (jofe)]

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 …

[S. L. (sldt)]

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. (sldt)]

an Johannes T. Fechner:
Probieren Sie Folgendes in main.asm:

loop_readByte:
...
...
; Enable Target UPDI:
  rcall  updi_enable

rcall sendNvmProgKey   ; <=== SLdt 2406211020
rcall systemReset      ; <=== SLdt 2406201909

; Send LDS instruction:
  rcall  sendLds
...

Mit dieser Änderung lässt sich, zumindest bei mir, die Signatur auslesen 
von ATtiny412, ATmega4809, AVR128DB28, AVR16DD28, AVR32EA28 und 
AVR16EB14.

[Johannes T. F. (jofe)]

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. (sldt)]

> an einem AVR128DB28 getestet
Bei meinem geht es, Date-code 2037K94; welchen hat Ihrer?

Nachtrag:
Also gut, nächster Versuch:

rcall systemReset       ; <=== SLdt 2406211132
rcall sendNvmProgKey    ; <=== SLdt 2406211020
rcall systemReset       ; <=== SLdt 2406201909

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

> 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.

[Johannes T. F. (jofe)]

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 …

[S. L. (sldt)]

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 ...

[Johannes T. F. (jofe)]

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:

• pymcuprog-main\pymcuprog\serialupdi\application.py
• pymcuprog-main\pymcuprog\serialupdi\constants.py
• pymcuprog-main\pymcuprog\serialupdi\link.py
• pymcuprog-main\pymcuprog\serialupdi\nvmp[0,2,3,4,5].py

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! :)

[Johannes T. F. (jofe)]

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):

loop_readByte:
[...]
    rcall   updi_enable
; Send LDCS instruction, to keep UPDI alive:
    clr     tmp0
    rcall   sendLdcs
; Wait for answer bytes from Target UPDI:
loop_readByte_waitLdcs:
    sbrc    updiFlags, UPDI_FLAGS_TIMEOUT_bp
    rjmp    loop_timeout
    sbrs    updiFlags, UPDI_FLAGS_RXC_bp
    rjmp    loop_readByte_waitLdcs
; Give the target MCU a bit of time:
    rcall   updi_wait25ms
; Send LDS instruction:
    rcall   sendLds
; Read answer byte from Target UPDI:
[...]

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 ...

[Veit D. (devil-elec)]

Hallo,

du hast meinen vollen Respekt!

[S. L. (sldt)]

> ... 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.

[Johannes T. F. (jofe)]

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 …

[Frank K. (fchk)]

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.

[Johannes T. F. (jofe)]

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.

[Veit D. (devil-elec)]

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.

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

> ... 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?

[Frank K. (fchk)]

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

[Johannes T. F. (jofe)]

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. seufz

Frank 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 ...

[S. L. (sldt)]

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?

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

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.

[Georg M. (g_m)]

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?

[Johannes T. F. (jofe)]

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.

[Johannes T. F. (jofe)]

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.

[S. L. (sldt)]

> 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.

[Johannes T. F. (jofe)]

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?

sendSts:
    push    [...]
; Wait for any previous transmission or reception to be completed:
sendSts_waitBusy:
    sbrc    updiFlags, UPDI_FLAGS_BUSY_bp
    rjmp    sendSts_waitBusy
; Send instruction code and address:
    [...]
    rcall   updi_tx
    rcall   wait10us
; Wait for first 'ACK' from Target UPDI:
sendSts_wait0:
    sbrc    updiFlags, UPDI_FLAGS_TIMEOUT_bp
    rjmp    sendSts_timeout
    sbrs    updiFlags, UPDI_FLAGS_RXC_bp
    rjmp    sendSts_wait0
; updiUartData_ram now contains the received byte.
    lds     tmp0, updiUartDataBuf_ram
    cpi     tmp0, UPDI_ACK
    brne    sendSts_invAnswer
; Send data byte:
    [...]
    rcall   updi_tx
; Wait for second 'ACK' from Target UPDI:
sendSts_wait1:
    [...]

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.

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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!

[Georg M. (g_m)]

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)

[S. L. (sldt)]

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.

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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 ...

[Johannes T. F. (jofe)]

Das Register NVMCTRL_STATUS enthält nach dem Schreibversuch 0x10, also 
Error Code 'Invalid Command'. Bleibt nun noch herauszufinden, woran das 
nun wieder liegt ...

[S. L. (sldt)]

> 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:

(3) Read byte from UPDI address space
(4) Chip erase
(5) Write fuse byte
3
Address: 1400
NVM version number: 2
LDS returned: 56

(1) Read SIB
(2) Read UPDI register
(3) Read byte from UPDI address space
(4) Chip erase
(5) Write fuse byte
5
Address: 1400 Data: AB Confirm (y/n): y
NVM version number: 2
Entering NVM Programming key...
ASI KEY STATUS: 10
ASI SYS STATUS: 28
Sending STS no. 1/4 ... Issuing System Reset...

(1) Read SIB
(2) Read UPDI register
(3) Read byte from UPDI address space
(4) Chip erase
(5) Write fuse byte
3
Address: 1400
NVM version number: 2
LDS returned: AB

(1) Read SIB
(2) Read UPDI register
(3) Read byte from UPDI address space
(4) Chip erase
(5) Write fuse byte

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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.

[Johannes T. F. (jofe)]

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:

Sending STS ...
04:55 44 00 10
02:55 13
OK
Sending STS ...
04:55 44 00 14
02:55 AB
OK
Waiting while NVMCTRL is busy ...
04:55 04 02 10
NVMCTRL_STATUS: 10
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.

[Johannes T. F. (jofe)]

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

[Frank K. (fchk)]

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

[S. L. (sldt)]

Warum nur, bitte, bauen Sie mitten in STS ein SYNCH ein, im Widerspruch 
zum Datenblatt (und Ihren früheren Versionen)?:

Sending STS ...
04:55 44 00 10
02:55 13

Werfen Sie das raus:

    brne    updi_sts_invAnswer
; Got first ACK. Send data byte:
    rcall   wait1ms
    sts     updiUartDataCount_ram, zero
    ldi     tmp0, UPDI_SYNCH
;   rcall   updi_appendBuf ; <=== SLdt 2406251318
    mov     tmp0, tmp2              ; Data byte to be written.

Sending STS ...
04:55 44 00 10
01:13

und schon funktioniert es.

Ich meine, im früheren sendSts stand doch auch nur:

; Send data byte:
    sts     updiUartDataBuf_ram, tmp2       ; Data byte to be written.
    ldi     tmp3, 1
    sts     updiUartDataCount_ram, tmp3 ; Transfer block size.
    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'.

[Johannes T. F. (jofe)]

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 ...

[S. L. (sldt)]

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.

[Johannes T. F. (jofe)]

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 ...

[S. L. (sldt)]

> ATtiny416 ... weigert sich ... auf jene LDS-Anfragen ...
> im Gegensatz zum 64DD28.

Na, dreimal dürfen Sie raten ...

; Branch according to NVM version:
  cpi    tmp0, '0'
;  breq  loop_readByte_nvm0  <=== SLdt 2406261335
; NVM version number != 0, e.g. AVR_DB and AVR_DD.
; These devices apparently need a more complicated procedure:

PS:
Dass das STS dann noch nicht läuft auf dem ATtiny, steht auf einem 
anderen Blatt.

[S. L. (sldt)]

> STS dann noch nicht läuft auf dem ATtiny

Warum dieses?:

; Hold target device in reset:
  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:

; EEERWR - EEPROM Erase and Write Enable:
  ldi    tmp0, low(NVMCTRL_CTRLA)
  ldi    tmp1, high(NVMCTRL_CTRLA)
  ldi    tmp2, 0x13

NVMCTRL.CTRLA.CMD ist beim ATtiny416 nur von 0 bis 7 definiert.

[Johannes T. F. (jofe)]

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:

    def enter_progmode(self):
        """
        Enters into NVM programming mode
        """
        # First check if NVM is already enabled
        [...]
        # Hold part in reset
        self.reset(apply_reset=True)
        # Put in the key
        self.readwrite.write_key(constants.UPDI_KEY_64, constants.UPDI_KEY_NVM)
        # Check key status
        [...]
        # Toggle reset
        self.reset(apply_reset=True)
        self.reset(apply_reset=False)
        # And wait for unlock
        [...]
        # Check for NVMPROG flag
        [...]
        self.logger.debug("Now in NVM programming mode")
        return True

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.

[Johannes T. F. (jofe)]

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:

rcall  updi_applyReset
rcall  wait5ms
rcall  updi_releaseReset
rcall  wait5ms
rcall  updi_enterNvmProgKey
rcall  wait5ms
rcall  updi_applyReset
rcall  wait5ms
rcall  updi_releaseReset
rcall  wait5ms
rjmp  loop_readByte_lds ; updi_lds folgt.

Trotzdem antwortet mein ATtiny416 nicht:

Address: 1100
02:55 E5
NVM version number: 0
03:55 C8 59
03:55 C8 00
0A:55 E0 20 67 6F 72 50 4D 56 4E
03:55 C8 59
03:55 C8 00
04:55 04 00 11

Error: Timeout while waiting for UPDI answer.

Er ist aber nicht defekt – mit dem mEDBG findet die Kommunikation 
problemlos statt.

[S. L. (sldt)]

> 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.

[Johannes T. F. (jofe)]

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?

[S. L. (sldt)]

> 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.

[Johannes T. F. (jofe)]

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:

Address: 1100
02:55 E5
NVM version number: 0
03:55 C8 59
03:55 C8 00
0A:55 E0 20 67 6F 72 50 4D 56 4E
03:55 C8 59
03:55 C8 00
04:55 04 00 11
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 ...

[Johannes T. F. (jofe)]

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.