Bootloader mit avr/boot.h

[Markus Altmann (Gast)]

Hallo,
Ich schreibe einen Bootloader für den ATmega162 und verwende dazu
avr-libc-1.0.3
Die Downloadroutine habe ich angehängt.

Zur Routine:
Die Routine soll immer den ganzen Applikationsbereich beschreiben,
und holt sich die binär-Daten dazu aus dem Empfangsbuffer aus dem UART
der über Interrupt betrieben wird. Die Interrupts sind deshalb aktiv,
sollte aber kein Problem sein, da diese in der BLS residieren.
Ob neue Daten im Buffer vorliegen wird über dessen Status überprüft, da
man bei binär-Daten kein EOF als return-Wert verwenden kann wie sonst
üblich, weil es sich bei EOF (=0xFF) auch um gültige Daten handelt die
zu programmieren sind

Problem:
Das seltsame daran ist, dass der Code meistens funktioniert.
Es kann aber vorkommen, dass manche Stellen im Flash unprogrammiert auf
0xFFFF hängen bleiben, es handelt sich dabei immer nur um 1 word, das
immer 2 byte von einer PAGE_SIZE Grenze entfernt ist, z.B.: auf
Byteaddresse 0x1026, 0x2306 oder 0x0514.

Ein nochmaliges Aufrufen der Routine schafft abhilfe, das entsprechende
0xFFFF lässt sich programmieren. Die Speicherzelle kann also nicht
defekt sein.
Welche Zelle und ob überhaupt betroffen ist scheint dem Zufall
überlassen zu sein. Ich tippe eher auf ein Timingproblem.

Den Verdacht das der UART dabei etwas falsch macht habe ich schon
ausgeräumt, indem ich mittels Debugled überprüft habe ob jemals ein
0xFFFF an boot_page_fill() übergeben wird. Das war definitiv nicht der
Fall.

Vielleicht kann mir jemand sagen der den Code mal überfliegt woran das
liegen kann?

Markus

[mthomas (Gast)]

Falls "die Interrupts aktiv sind" vielleicht die Schreibroutine mit
cli/sei umklammern. Die SPM-Funktionen sind, wenn recht erinnert,
empfindlich gegen Unterbrechnungen, da bestimmte Timings eingehalten
werden muessen.
Wuerde auch versuchen, ein Protokoll zum UART upload zu nutzen, eine
Seite an den uC schicken, der seinerseit die Bytes erstmal puffert und
dann (bei angeschalteten INTs) aus dem Puffer in die Flash-Seite
schreibt. Die Erkennung ueber RX Interrupt koennte man dann weglassen
und evtl. Unterbrechnungsprobleme umgehen. (Im Prinzip so wie in
AVR910/109 und im STK500-Protokoll beschrieben)
Die Reaktivierung (RWW) scheint mir etwas seltsam, habe aber grade
keine Details parat.

HTH
Martin

Vielleicht hilft dieser Code etwas weiter ("Eigenwerbung"):
http://www.siwawi.arubi.uni-kl.de/avr_projects/#avrprog_boot

[Markus Altmann (Gast)]

Hallo Martin,
Danke für die Tips,
Ich habe schon versucht die Funktion boot_page_write() mit den
Interrupts disabled auszuführen, allerdings bringt das keinen
Unterschied.
Wenn ich dich richtig verstehe meinst du man sollte so eine Art
Handshake , so ähnlich wie XON/XOFF, auf der UART Schnittstelle
implementieren.
Das wollte ich bisher vermeiden, um Platz zu sparen.

Mir ist allerdings im Datenblatt nichts aufgefallen, dass man
Interrupts die im Bootloader-Sektor liegen während des
Flash-Programmierens nicht aktiviert haben sollte.

Oder liege ich da falsch?

[Fiffi (Gast)]

Hallo Markus,

>Wenn ich dich richtig verstehe meinst du man sollte so eine Art
>Handshake , so ähnlich wie XON/XOFF, auf der UART Schnittstelle
>implementieren.
>Das wollte ich bisher vermeiden, um Platz zu sparen.

Ich würde auf keinen Fall einfach nur die nackten Binärdaten
übertragen.

Vorschlag:
- Länge der Page empfangen
- CRC16 Summe empfangen
- - ein Byte empfangen
- - in Puffer übertragen
- - zur CRC16 hinzufügen
- CRC16 Summen vergleichen
- Alle Interrupts aus
- Page brennen
- Alle Interrupt ein
- ein "OK" o.ä. senden

Nächste Page ...


Gruß

Fiffi

[Jörg Wunsch (Gast)]

Man könnte natürlich gleich irgendwas wie X-Modem benutzen...