Forum: Mikrocontroller und Digitale Elektronik AVRDUDE, STK500 Bootloader und XMega


von Holger M. (dl2gmh)


Lesenswert?

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

von Mike J. (linuxmint_user)


Lesenswert?

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.

von spess53 (Gast)


Lesenswert?

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

von Holger M. (dl2gmh)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Mike J. (linuxmint_user)


Lesenswert?

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.

: Bearbeitet durch User
von Holger M. (dl2gmh)


Lesenswert?

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?

von Holger M. (dl2gmh)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Holger M. (dl2gmh)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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:
1
#------------------------------------------------------------
2
# ATxmega384C3
3
#------------------------------------------------------------
4
5
part parent ".xmega"
6
    id          = "x384c3";
7
    desc        = "ATxmega384C3";
8
    signature   = 0x1e 0x98 0x45;
9
    usbpid      = 0x2fdb;

Das ist schon seit Version 6.0 drin, kann es sein, dass dein
AVRDUDE einfach recht alt ist?

von Mike J. (linuxmint_user)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

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

von Holger M. (dl2gmh)


Lesenswert?

Jörg W. schrieb:
> Nee, nimm lieber einen Xmega.

Das war auch mein erster Ansatz. Siehe die Ergebnisse hier:
1
%avrdude -p x384c3 -c stk500v2 -P COMPORT -U fl:w:test.hex:i
2
3
avrdude: stk500v2_program_enable(): program enable instruction not defined for part "ATxmega384C3"
4
avrdude: initialization failed, rc=-1

Deshalb hatte ich den Code für program_enable und chip_erase eingebaut 
(siehe Post weiter oben). Dessen Ergebnis hier:
1
...
2
Reading |                                                    | 0% 0.00savr_read(): error reading address 0x0000
3
    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...!?!

von Holger M. (dl2gmh)


Lesenswert?

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.

von Holger M. (dl2gmh)


Lesenswert?

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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Holger M. (dl2gmh)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Holger M. (dl2gmh)


Angehängte Dateien:

Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.