Hallo,
vor wenigen Stunden gelang es mir den seriellen STK500 Bootloader von
Peter Fleury auf den XMega384C3 portieren. Warum tut man sowas? Nun,
bisher verwendete ich den Mega328P damit, was prima funktionierte. Auf
solch einen Komfort möchte ich nur ungern verzichten. Der BL kommt
übrigens via AVRDUDE und AVR-ISP MKII in den Chip.
Das Problem ist, dass AVRDUDE die Anwendung über den Bootloader nicht
laden kann, da offensichtlich die Definition für den Chip fehlt. Wie
macht man so eine Definition? Nehme an, das gehört in die avrdude.conf.
Das AVRDUDE.PDF ist dabei leider nicht besonders hilfreich, da es nur
die verfügbaren Oprionen enthält, nicht jedoch eine Beschreibung, was
davon für eine erfolgreiche Programmierung per STK500v2 Protokoll nötig
ist. Die Signatur kann ich lesen, alles andere geht nicht.
Hat das schon mal jemand gemacht? Oder weiss das nur Jörg?
Vielen Dank schon mal für Euren Input.
Holger
Holger M. schrieb:> da offensichtlich die Definition für den Chip fehlt
Du musst schon die richtige Fuse setzen die dem Chip sagt dass da jetzt
ein Bootloader drauf ist, sonst springt der Zeiger gleich in den
Applikationsbereich und führt einfach dein Programm aus.
Ich habe einen ISP MKII Clone, der funktioniert auch unter AVR-Studio7,
ich musste nur die Firmware an der Stelle umschreiben in der die Version
der Firmware drin steht, denn diese Nummer erwartet AVR-Studio. Wenn die
falsche Nummer vom USB MK-II zum AVR-Studio übertragen wird verweigert
das AVR-Studio die Arbeit und liest den Chip auf der Prototypenplatine
auch nicht aus.
Die Fuse für den Bootloader kann man aber auch manuell per AVRdude
setzen.
Hi
> Warum tut man sowas? Nun,>bisher verwendete ich den Mega328P damit, was prima funktionierte. Auf>solch einen Komfort möchte ich nur ungern verzichten.
Welcher 'Komfort'?
MfG Spess
Mike J. schrieb:> Du musst schon die richtige Fuse setzen die dem Chip sagt dass da jetzt> ein Bootloader drauf ist, sonst springt der Zeiger gleich in den> Applikationsbereich und führt einfach dein Programm aus.
Hi Mike,
danke für Deinen Beitrag. Wieso Fuse? Sobald der BL drauf ist (siehe
mein Post) befindet sich sowieso nur 0xFF im Applikationsbereich, was
vom Chip einfach übersprungen wird bis er beim BL ankommt und diesen
sogleich ausführt.
Zurück zur Frage: Was muss in die avrdude.conf, damit AVRDUDE per
seriellem Anschluss mittels STK500v2 Protokoll seine Programmieraufgaben
erledigen kann? (Man kann da übrigens nix mit der Maus machen...)
-------------
Spess53 schrieb:> Welcher 'Komfort'?
Hi Spess, guter Einwand :-))
Der 384 ist sozusagen ein drop-in-replacement für den 328P. Die
Updatemaschinerie gibt es schon - es ist eher mein(e) eigene(r),
persönliche(r) Komfort(zone)...
-------------
Bitte um weitere hilfreiche Hinweise.
Holger
Holger M. schrieb:> Die Signatur kann ich lesen, alles andere geht nicht.
Was passiert denn genau?
Normalerweise würde man sich den am besten passenden Eintrag suchen
und dann per "chaining" davon nur die Dinge abändern, die beim
gewünschten Controller anders sind. Diese Möglichkeit, Einträge
miteinandern zu verketten, gibt's ja seit AVRDUDE 6.
Holger M. schrieb:> gelang es mir den seriellen STK500 Bootloader von> Peter Fleury auf den XMega384C3 portieren
Weshalb nutzt du nicht gleich den USB-Bootloader von Atmel?
Lade dir die AVR1916.zip runter.
https://www.mikrocontroller.net/topic/goto_post/3302905
Gehe in das Verzeichnis "XMEGA_bootloaders_v104/binaries/".
dort findest du unter anderem die Datei "atxmega384c3_104.hex".
Flashe sie auf deinen XMega384C3 in den Bootloaderbereich und ziehe vor
dem Start oder vor dem nächsten Reset den Boot-Pin (PE5 beim C3)
eine kleine Weile nach GND damit der Bootloader starten kann.
Zum programmieren in den App-Bereich kann man dann einfach "Flip" von
Atmel nehmen und über dem USB-Anschluss des Controllers das Programm
flashen.
Jörg W. schrieb:> Was passiert denn genau?
Guten Abend Jörg,
der Dude startet, liest die Signatur, gibt sie korrekt aus und beendet
sich wieder ohne die angegebenen -U Kommandos auszuführen.
Das Lesen der Sig geht, seit ich folgende Eintragung beim 384
hinzufügte:
1
pgm_enable = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1",
2
"0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0";
und
1
memory "signature"
2
size = 3;
3
read = "0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0",
4
"0 0 0 0 0 0 a1 a0 o o o o o o o o";
5
;
Das ist jeweils eine Kopie eines anderen Eintrages weiter oben im File.
Weitere Versuche mit ähnlichen Einträgen für z.B. den Flash Bereich
blieben bisher ohne Erfolg.
Woran erkennt man Einträge, die fürs STK500 Protokoll benötigt werden?
Mike J. schrieb:> Weshalb nutzt du nicht gleich den USB-Bootloader von Atmel?
Nun, das hat zwei Gründe: einerseits überchreibe ich mit meinem BL den
bereits von Atmel gelieferten DFU-BL und andererseits ist der Chip
seriell über USARTD0 angeschlossen.
Holger M. schrieb:> Woran erkennt man Einträge, die fürs STK500 Protokoll benötigt werden?
Das Protokoll ist da weitgehend egal, die Devices und die
Programmers werden jeweils völlig separat abstrahiert. (Es gibt
ein paar Parameter, die in der Tat protokollabhängig sind.)
Allerdings ist das STK500v1-Protokoll natürlich hornalt und war nie
für Devices dieser Größenordnung konzipiert worden. Es ist also
gut möglich, dass sich da noch irgendwo Bugs verstecken. Atmel hat
ja nicht umsonst damals eine Version 2 des Protokolls für ihre STK500
ins Leben gerufen, nachdem sie bemerkt haben, welche Limitierungen
ihr vergleichsweise simples erstes STK500-Protokoll so hatte.
Jörg W. schrieb:> Das Protokoll ist da weitgehend egal...
Ok, dann versuche ich's mal mit dem Eintrag des 328P zu dem ich verlinke
und dessen Sektionen FLASH und EEPROM sodann überschreibe.
Sind die Sektionen Application, Apptable und Usersig durch das Verlinken
automatisch verwendbar, oder müsste man sich auf Flash und EEProm
beschränken?
Das V1 Protokoll ist steinalt, ja. Zumindest im Quellcode von Peter
Fleury steht etwas von V2. Wenn ich nicht irre, sind die Adressen
immerhin 32 bit. Einen Versuch ist es dann allemal wert.
Danke einstweilen - ich werde berichten.
Holger M. schrieb:> Jörg W. schrieb:>> Das Protokoll ist da weitgehend egal...>> Ok, dann versuche ich's mal mit dem Eintrag des 328P zu dem ich verlinke> und dessen Sektionen FLASH und EEPROM sodann überschreibe.
Nee, nimm lieber einen Xmega. Die haben eine ziemlich andere
Speicherstruktur als die alten Megas, beispielsweise durch die
separaten Sektionen für Bootloader und Application.
Stimmt, du schriebst von STK500v2. Das sollte es eigentlich hergeben,
die Xmegas brauchbar genug zu behandeln.
Ähem, Moment mal:
Also mit XUbuntu 16.04 hat man automatisch AVRdude in der Version 6.2
drauf.
@ Holger
Weshalb möchtest du keine USB-Buchse dort anschließen?
Ich hatte an den ATXmega128A4U an Pin PD6 und PD7 den USB-Anschlus dran,
aber ich habe den USB-Anschluss nur zum beschreiben der neuen Firmware
genutzt. Den selben Anschluss habe ich auch zur UART-Kommunikation
genutzt.
Oder willst du an deinen UART einen Funkempfänger anhängen und dein
Board dann über Funk neu flashen können?
> Welcher Komfort?
Das frage ich mich auch. Als ich zum ersten mal mit Arduinos
experimentiert hatte, fand ich den Bootloader zunächst ganz toll. Denn
ich brauchte keinen Programmeradapter mehr. Nur noch ein USB Kabel statt
zwei.
Aber: Den ISP Programmer habe ich nunmal schon früher für eigene
Konstruktionen ohne Arduino gekauft, also kann ich den nicht mehr
wegsparen.
Außerdem brauche ich den ISP Programmer manchmal eben doch, zum Beispiel
um eine Fuse umzustellen. Ich habe auch schon mehrfach Arduino Nano
Clones gekauft, wo der Bootloader fehlte.
Und es stellte sich zwischenzeitlich heraus, dass ein USB Kabel statt
zwei doch nicht komfortabler ist. Denn dann muss ich immer mein
serielles Terminal schließen, um ein neues Programm zu flashen. Und
danach muss ich das serielle Terminal wieder neu verbinden, um Debug
Meldungen sehen zu können. Bei zwei Kabeln kann ich einfach beide
gleichzeitig verwenden (serielle Konsole und über ISP flashen).
Und wenn ich nun aus gutem Grund sowieso immer einen ISP Stecker
einplane und auch immer einen ISP Programmieradapter habe ist der andere
Weg über Bootloader vollkommen überflüssig.
Bei Geräten, wo der Enduser selbst Firmware-Upgrade installieren können
soll, liefere ich einfach einen ISP Adapter mit - je nach Wunsch im
Gerät fest eingebaut. Wer das Feature wirklich haben will, bezahlt den
nötigen Aufpreis gerne.
read operation not supported for memory "signature"
4
avrdude: error reading signature data for part "ATxmega384C3", rc=-2
5
avrdude: error reading signature data, rc=-1
Also noch den Abschnitt mit der Signatur dazu (hatte ich auch gepostet):
1
...
2
avrdude: Device signature = 0x1e9845
3
avrdude: NOTE: Programmer supports page erase for Xmega devices.
4
...
5
for a chip-erase, use the -e option.
6
avrdude: reading input file "test.hex"
7
avrdude: writing flash (29388 bytes):
8
9
Writing | | 0% 0.00savrdude: stk500v2_page_erase(): this function must never be called
10
Writing | # | 1% 0.09s ***failed;.....
Na gut, dann halt mit -e:
1
...
2
Writing | | 0% 0.00savrdude: stk500v2_paged_write: write instruction not defined for part "ATxmega384C3"
3
Writing | # | 1% 0.12s ***failed;...
Also doch nicht so einfach?
Nehme ich statt dessen einen 328p (mit -F) schreibt er was, nur halt max
32 KB. Der Verify klappte auch nicht, wobei ich nicht genau abklärte, ob
es am BL oder dem Dude lag.
Mit einer Kopie des m2560 machte ich danach in einer leeren avrdude.rc
weiter. Aber die Wirkung der Befehle (read, read_lo, read_hi, write...)
erschliesst sich mir nicht. Wie kann ich heraus finden, welche
Eintragungen ich für den Chip machen muss?
Gibt es eine Map, die die Zuordnung von Definition-aus-arvdude.conf zu
verwendetem Befehl in STK500v2 Sprache definiert? Ich fürchte die gibt
es nur in Deinem Code...!?!
Mike J. schrieb:> Weshalb möchtest du keine USB-Buchse dort anschließen?
Mike, manchmal hat man einfach keine Wahl. Die weltweit einfachste
Lösung wäre auch mir lieber gewesen, aber es gibt oft gewisse Vorgaben,
die es einzuhalten gilt. Vorgaben betreffen z.B. die Platzverhältnisse,
die Möglichkeiten des Computers an das das Device angeschlossen ist,
oder die Machbarkeit, also was muss man in der Produktion alles tun bis
alles fertig ist. Weiter oben las ich mal was von einem ins Gehäuse
eingebauten Programmer - das wäre z.B. undenkbar.
Danke für Deinen Lösungsweg mit dem USB Bootloader. Diesmal muss ich mit
UART auskommen.
Stefan U. schrieb:>> Welcher Komfort?>> Das frage ich mich auch.
Ich bin nicht ganz sicher, ob Dein Beitrag eher Pro Bootloader, oder
dann doch dagegen ist. Möglicherweise vermischen sich Deine Eindrücke
aus Entwicklung, Produktion und Nutzung.
Höchstwahrscheinlich gibt es sowieso keine allgemeingültige Lösung
dafür, davon bin ich überzeugt.
Von dem was Du schreibst vermute ich, Du bist viel öfter Entwickler als
Produzent oder Nutzer. Da würde ich es nicht anders machen - immer den
schnellsten ISP Programmer nehmen und hoffen, dass ein UART für's
Terminal frei ist. ;-)
In diesem Sinne - viel Spass beim Entwickeln!
Holger M. schrieb:> avrdude: stk500v2_program_enable(): program enable instruction not> defined for part "ATxmega384C3"
Hmm, ja. Xmegas kann man halt schlecht auf einen STK500 montieren,
insofern gibt's auch keine Definitionen dafür bei Atmel.
Auch, wenn ein AVRISPmkII oder STK600 im Prinzip STK500v2-Protokoll
sprechen: für Xmega benutzen sie stattdessen Xprog. AVRDUDE ist
entsprechend darauf ausgerichtet. Nach etwas mehr Nachdenken fürchte
ich, dass du die beiden (STK500v2-Protokoll und Xmega) irgendwie auf
die Schnelle ohne große Modifikationen am AVRDUDE nicht verheiratet
bekommen wirst.
Eigentlich wäre es das sinnvollste, für Xmegas einen Bootloader zu
bauen, der selbst wiederum Xprog spricht.
Jörg W. schrieb:> Auch, wenn ein AVRISPmkII oder STK600 im Prinzip STK500v2-Protokoll> sprechen: für Xmega benutzen sie stattdessen Xprog. AVRDUDE ist> entsprechend darauf ausgerichtet. Nach etwas mehr Nachdenken fürchte> ich, dass du die beiden (STK500v2-Protokoll und Xmega) irgendwie auf> die Schnelle ohne große Modifikationen am AVRDUDE nicht verheiratet> bekommen wirst.
Möglicherweise muss man sich in diesem Falle von der XMega/Xprog
Denkweise frei machen. Der BL emuliert das Ganze ja nur. In der
bisherigen Version gab er sich als m328p aus, weil die Signatur
entprechend gesetzt war. Letztlich hat der Schreibcode die Bytes aus den
Frames genommen und weggeschrieben. Die Schreibfunktionen habe ich jetzt
mit denen des XMega ersetzt. Was ich jetzt benötige ist eine
Partbeschreibung, die einen Mega mit 384 kb Flash definiert. Im Prinzip
ein m328p, der bei 32kb nicht aufhört zu schreiben.
Mittlerweile habe ich auch die Sourcen von Avrdude durchgelesen (das
wollte ich eigentlich vermeiden). Soweit ich das sehe könnte mein Ansatz
funktionieren. Es liegt mir fern etwas am Dude zu ändern. Oder übersehe
ich das was?
Holger M. schrieb:> Möglicherweise muss man sich in diesem Falle von der XMega/Xprog> Denkweise frei machen.
Möglicherweise kannst du aber eben genau das auch nicht, weil der
Xmega eine komplett andere Speicherorganisation hat.
Aber du kannst natürlich versuchen, das wie einen normalen megaAVR
zu behandeln, denn für den Bootloader willst du ja sowieso immer nur
den application flash (und maximal noch EEPROM) behandeln können.
Im Prinzip müsste es ja dann genügen, den Flash einfach nur groß
genug zu deklarieren in deinem Eintrag. megaAVRs mit 256 KiB gab's
ja auch real auf dem STK500 schon (STK500 + STK501 mit ATmega2561),
insofern sollte die Flashgröße an sich nicht das Problem darstellen
im STK500v2-Protokoll.
Jörg W. schrieb:> Aber du kannst natürlich versuchen, das wie einen normalen megaAVR> zu behandeln, denn für den Bootloader willst du ja sowieso immer nur> den application flash (und maximal noch EEPROM) behandeln können.> Im Prinzip müsste es ja dann genügen, den Flash einfach nur groß> genug zu deklarieren in deinem Eintrag. megaAVRs mit 256 KiB gab's> ja auch real auf dem STK500 schon (STK500 + STK501 mit ATmega2561),> insofern sollte die Flashgröße an sich nicht das Problem darstellen> im STK500v2-Protokoll.
Genau so siehts aus.
Allerdings taucht jetzt ein ganz anderes Problem auf. Habe mal einen
frischen Eintrag in die avrdude.rc eingebaut (s. Anhang). Lesen ist kein
Problem, beim Schreiben ins Flash dann folgender Fehler in Form eines
Dialogfensters:
1
Problemsignatur:
2
Problemereignisname: APPCRASH
3
Anwendungsname: avrdude.exe
4
Anwendungsversion: 0.0.0.0
5
Anwendungszeitstempel: 000755f0
6
Fehlermodulname: avrdude.exe
7
Fehlermodulversion: 0.0.0.0
8
Fehlermodulzeitstempel: 000755f0
9
Ausnahmecode: c0000005
10
Ausnahmeoffset: 0001eb30
11
Betriebsystemversion: 6.1.7601.2.1.0.256.48
12
Gebietsschema-ID: 1031
Auf dem eigentlichen Linux Zielsystem habe ich es noch gar nicht
ausprobiert. Avrdude liegt übrigens in Version 6.3 vor.
Wie muss denn nun ein solcher Definitionseintrag aussehen, damit dieser
Crash ausbleibt?
Holger M. schrieb:> Wie muss denn nun ein solcher Definitionseintrag aussehen, damit dieser> Crash ausbleibt?
Keine Ahnung, denn ich habe schlicht keine Idee, was mir diese
paar Zeilen wirklich sagen sollen. Ein Stacktrace wäre das mindeste,
was man dafür benötigt.