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
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
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?
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.