AVR - Bootloader

[Stef J. (lastj)]

Hallo,

Habe mich entschlossen für meinen atxmega128a4u einen Bootloader zu 
schreiben. Dazu habe ich mich 
belesen(http://blog.schicks.net/wp-content/uploads/2009/09/bootloader_faq.pdf 
und 
http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung). 
Im Anhang befindet sich noch meine recht einfache main.c. In dieser 
möchte ich die avr/boot.h einbinden. Allerdings erzeugt dies einen 
Fehler den ich nicht beheben kann:

mingw32-make all 
'Building file: ../src/main.c'
In file included from ../src/main.c:20:0:
c:\avr8-gnu-toolchain\avr\include\avr\boot.h:116:6: error: #error AVR processor does not provide bootloader support!
 #    error AVR processor does not provide bootloader support!
      ^
c:\avr8-gnu-toolchain\avr\include\avr\boot.h:127:4: error: #error Cannot find SPM Enable bit definition!
 #  error Cannot find SPM Enable bit definition!
'Invoking: AVR Compiler'
avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atxmega128a4u -DF_CPU=32000000UL -MMD -MP -MF"src/main.d" -MT"src/main.d" -c -o "src/main.o" "../src/main.c"
src/subdir.mk:18: recipe for target 'src/main.o' failed
    ^
mingw32-make: *** [src/main.o] Error 1

Wenn ich mir den "iox128a4u.h" anschaue dann sollten die defines für die 
boot.h gesetzt werden. Beim Aufruf des Compilers wird auch die richtige 
mmcu angegeben. Wenn ich die boot.h auskommentiere, dann läuft der 
Compilierungsvorgang anstandslos durch.
Die boot.h benötige ich, da der Bootloader anscheind andere ISR-Vektoren 
definiert. Dazu soll ich folgende Anweisungen machen:

MCUCR = (1<<IVCE);
MCUCR = (1<<IVSEL);

Zudem möchte ich die fertigen Flash-Funktionen in boot.h verwenden.

Als Entwicklungssystem verwende ich die aktuelle avr toolchain von 
ATMEL(http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx) und 
die Eclipse IDE + AVR Eclipse Plugin(2.4.1).

Mal sehen ihr für Ideen bzw. Lösungsvorschläge habt. Grüße!

[Stephan B. (matrixstorm)]

Hallo

Da sich bisher niemand gemeldet hat, mach ich mal den Anfang:

Fuer mein relativ neues, vermutlich langzeit Projektchen
 ( http://matrixstorm.com/avr/avrstick )

Die Seiter ist leider noch im Aufbau.
Softwaretechnisch bin ich da weiter.
Ich habe ich den Bootloader der die Programmierung per
MassStorage erlaubt quasi fertig (naja, sagen wir, funktionsfaehig und 
stabil) - alles ohne boot.h ...

Ich beantworte dir gern deine Fragen - besuch mich einfach im Teamspeak 
3:

ts3server://vps.matrixstorm.com:10987?nickname=StefJar

MfG

[Seppi (Gast)]

Uuuuiiii.
Der Booloader macht Sinn.

Was noch fehlt:
Verschlüsselung

[Knut B. (Firma: TravelRec.) (travelrec)]

Stephan B. schrieb:
> Fuer mein relativ neues, vermutlich langzeit Projektchen
>  ( http://matrixstorm.com/avr/avrstick )

Hmm - ein ziemlich hässliches Entlein. Nix für ungut, aber das Routing 
könnte noch ein kleines Facelifting gebrauchen. Wo sind eigentlich die 
keramischen Abblockkondesatoren an jedem Versorgungspaar des Controllers 
abgeblieben?

[Stephan B. (matrixstorm)]

Knut Ballhause schrieb:
> Hmm - ein ziemlich hässliches Entlein.

Ja stimmt schon - danke fuer das Feedback.

Ich hatte ersteinmal nur eine Platform zum testen des Bootloaders 
gebraucht und mir ein Redesign fuer spaeter vorgenommen.
Und wie das "immer" so ist: Als das dann aber das bisherige so schoen 
lief, ist es ersteinmal dabei gebieben...

Ich naechster Zeit wollte ich ersteinmal weiter Zeit fuer die 
Softwareschiene investieren: Sprich online modifizier- und testbare 
Tutorials...
...ein Redesign auf einen DIP64 Adapter, basierend auf 
https://github.com/maugsburger/smbb ist aber schon geplant.

Knut Ballhause schrieb:
> Wo sind eigentlich die
> keramischen Abblockkondesatoren an jedem Versorgungspaar des Controllers
> abgeblieben?

;-)
Auf der kleinen Platine eingespart (funktioniert auch ohne weil kurze 
Leitung und hohe Kapazitaet nach Regler).
Ich habe aber auch einmal testweise einen TQFP64 Adapter mit Wrapwire 
"umgebaut" - dort hat jeder Vcc Pin einen 0.1uF spendiert bekommen.

Bilder folgen in Kuerze.

MfG

[Stephan B. (matrixstorm)]

Ich wuerde ggf. gern auch noch einen Bootloader haben/machen, der einen 
AVR ISPMKII emuliert.

Falls jemand Lust/Interesse hat - bitte melden.
(Ggf. du, Stef Jar?)

MfG

[Knut B. (Firma: TravelRec.) (travelrec)]

Stephan B. schrieb:
> Als das dann aber das bisherige so schoen
> lief, ist es ersteinmal dabei gebieben...

Ist schon recht, aber dann würde ich die Bilder nicht online stellen ;-)

Stephan B. schrieb:
> Ich naechster Zeit wollte ich ersteinmal weiter Zeit fuer die
> Softwareschiene investieren: Sprich online modifizier- und testbare
> Tutorials...

Naja - die Hardware ist der erste Schritt, die Software der zweite. Wenn 
Du Dich also ärgerst, warum Deine Software nicht so wie erwartet läuft, 
könnte es durchaus auch an einer vergurkten Hardware liegen. Auch mit 
Fädeldraht auf Lochraster kann man ein sauberes Design hinbekommen, wenn 
man sich ein bisschen an die Physik hält. Damit kann man dann seine 
Software testen.

Stephan B. schrieb:
> Auf der kleinen Platine eingespart (funktioniert auch ohne weil kurze
> Leitung und hohe Kapazitaet nach Regler).

Die fetten Elkos machen gegen Schaltspitzen im XMega erst mal gar 
nichts, weil sie viel zu träge und zu hochohmig sind. Das sieht man 
auch, wenn man mal ein längeres USB-Kabel zwischen Dongle und Rechner 
hat. Wenn die Kiste trotzdem rennt, ist es Zufall oder Glück. Vielleicht 
hast Du mal einen Oszi zur Hand, mit dem Du die Versorgungsspannung mal 
auf Ripple/Störungen prüfen kannst.

[Stef J. (lastj)]

Hey Stephan,

@Ich wuerde ggf. gern auch noch einen Bootloader haben/machen, der einen
AVR ISPMKII emuliert.

Ich will zuerst mal einen Bootloader selber schreiben, welcher sich mit 
meiner Toolchain kompilieren lässt.

Auf deiner Webseite ist kein Source-Code für deine Bootloader 
hinterlegt. Vlt. kannst du mir ein Demoprojekt mal zukommen lassen, was 
ich studieren kann.

Grüße aus Jena ;-)

[Stephan B. (matrixstorm)]

Stef Jar schrieb:
> @Ich wuerde ggf. gern auch noch einen Bootloader haben/machen, der einen
> AVR ISPMKII emuliert.

Ui, das freu mich - weil spart mir Arbeit ;-)
Ich helfe dir aber natuerlich gern.

Stef Jar schrieb:
> Ich will zuerst mal einen Bootloader selber schreiben, welcher sich mit
> meiner Toolchain kompilieren lässt.

Ueberhaupt kein Problem.
Verzichte auf die boot.h - die ist meines Wissens nacht nicht fuer die 
XMegas portiert.
Letztendlich ist ein Bootloader ein bissel Linkermagic (Code in 
Bootloadersektion platzieren) + setzen einiger Register (vermutlich 2) 
in Firmware zur Interruptumbiegung...

Fragen beantworte ich dir gern - am Liebsten per Sprache (Telefon oder 
halt Teamspeak).

Stef Jar schrieb:
> Grüße aus Jena ;-)

Hehe, Grüße aus Ilmenau ;-)

[Stef J. (lastj)]

Ich habe das Problem inzwischen gelöst und mein eigener Bootloader läuft 
schön rund. Für alle die einen eigen programmieren wollen hier meine 
Vorgehensweise:

@bootloader aktivieren:
Es wird ein Programmer benötigt(JTAG).
Das Setzten der BOOTRST Fuse damit der Bootloader zum reset(hard und 
weich) angesprungen kann. Die FUSE kann NICHT (auch nicht direkt aus dem 
Programm) mit Hilfe des NVM Controllers verändert werden

@Bootloader Firmware schreiben:
1.) in einem extra Projekt mit einem extra Makefile
2.) dem Linker muss mitgeteilt werden, wo der Code im Flashspeicher hin 
soll
das geht über diesen Linkerparameter: -Wl,-section-start=.text=0x20000
der Hexwert ist nur für einen ATXmega128a4u gültig. Einfach mal im 
Datenblatt nachschaun
3.) Programm:
3.1) die Interrupt Vektoren Tabelle liegt in einem anderen 
Speicherbereich. Daher muss ein Flag gesetzt werden:
PROTECTED_WRITE (PMIC.CTRL, (PMIC_HILVLEN_bm 
|PMIC_MEDLVLEN_bm|PMIC_LOLVLEN_bm | PMIC_IVSEL_bm));

3.2) zum Beschreiben des Flashes empfehle ich den ATMEL code aus dem 
AVR1316 notes. Zum Ablauf:
I) Page löschen (SP_EraseApplicationPage)
II) Page laden (SP_LoadFlashPage)
III) Page flashen (SP_WriteApplicationPage)
ggf noch mit hilfe von SP_WaitForSPM warten bis die Operation 
abgeschlossen ist. ggf mit hilfe von (NVM.STATUS & NVM_FBUSY_bm) checken 
ob der Flash fertig gelöscht/beschrieben wurde
Die Größe der Flashpage und damit des Zwischenpuffers entnimmt man aus 
der Konstante "APP_SECTION_PAGE_SIZE"