Hat hier eigentlich schon einmal jemand getestet, was der opcode FFFF auf neuen AVRs macht? Angeblich handelt es sich um "SBRS R31,7", wenn die neuen AVRs zum Ur-AVR noch kompatibel sind: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=104956#104956 In neuen Datenblättern ist dieses aber nicht mehr dokumentiert, und ausprobiert hat es anscheinend auch niemand. Warum ist das wichtig? Bei einigen Bootloadern kann u.U. eine Fehlfunktion auftreten, bei der der Speicher vor dem bootloader gelöscht und mit FFFF gefüllt ist. In diesem Fall sollte der Bootloader nach einem reset noch gestartet werden.
Hi. Ausserhalb eines DEBUGs wird 0xffff wie NOP behandelt. (Und es ist offiziell eine "invalid instruction".) Das Don't care innerhalb der SBRS Spezifikation wuerde abgeschafft, und das entsprechende Bit muss jetzt "0" bei einer SBRS Instruktion sein. (Damit ist neuer Code kompatibel auf alten Kernen.) MfG
Danke! Hast Du dazu zufällig eine Quelle? So lange die Befehle immer in einer gerade Anzahl auftauchen, ist es ja zum Glück auch egal, ob FFFF als NOP oder als SBRS interpretiert wird.
Hallo Das mit SBRS ist auf Seite 129 von http://www.atmel.com/images/doc0856.pdf. Das 0xFFFF wie NOP behandelt wird habe ich in irgendeinen Atmel Datenblatt gelesen - welches faellt mir aber nicht mehr ein. Aber zur Verifikation kannst du einfach einen neueren avr-objdump nehmen. Aus 0xFFFF wird dann ".word 0xffff ; ????". MfG
Tim schrieb: > Bei einigen Bootloadern kann u.U. eine > Fehlfunktion auftreten, bei der der Speicher vor dem bootloader gelöscht > und mit FFFF gefüllt ist. Das ist hart. Aber das ist kein Problem des AVRs, sondern des Bootloaders, welches einfach mal gefixt werden müsste. Gruß Jobst
Jobst M. schrieb: > Tim schrieb: >> Bei einigen Bootloadern kann u.U. eine >> Fehlfunktion auftreten, bei der der Speicher vor dem bootloader gelöscht >> und mit FFFF gefüllt ist. > > Das ist hart. Aber das ist kein Problem des AVRs, sondern des > Bootloaders, welches einfach mal gefixt werden müsste. Locker bleiben. Diese Situation tritt auf, wenn der Upload des Userprograms abgebrochen wird. Dann kann z.B. eine Page gelöscht aber noch nicht mit neuen Daten beschrieben sein und enthält FFFF. Wenn das die ersten Flash-Seite betrifft, wird die Ausführung mit dem Reset-Vektor beginnen, der jetzt eben FFFF enthält. Ich vermute dass die meisten der tollen seriellen Bootloader in dem Falle einfach das Device korrupt zurücklassen.
Stephan B. schrieb: > Das mit SBRS ist auf Seite 129 von > http://www.atmel.com/images/doc0856.pdf. Da ist allerdings bit 3=0. Angeblich war es ein Bug im Ur-90S1200, dass dort bit 3 egal war. > Das 0xFFFF wie NOP behandelt wird habe ich in irgendeinen Atmel > Datenblatt gelesen - welches faellt mir aber nicht mehr ein. > Aber zur Verifikation kannst du einfach einen neueren avr-objdump > nehmen. > Aus 0xFFFF wird dann ".word 0xffff ; ????". Hm. Also ein Illegaler Opcode.
Tim schrieb: > Warum ist das wichtig? Bei einigen Bootloadern kann u.U. eine > Fehlfunktion auftreten, bei der der Speicher vor dem bootloader gelöscht > und mit FFFF gefüllt ist. In diesem Fall sollte der Bootloader nach > einem reset noch gestartet werden. Es ist doch egal was vorm Bootloader im Flash steht! Wenn man einen Bootloader verwendet, dann wird per FUSE die Startadresse des Bootloaders eingestellt und nach dem Reset immer diese angesprungen. Warum sollte das nach einem missglückten/abgebrochenem Flashvorgang aus dem Bootloader nicht mehr gehen? Sascha
Sascha Weber schrieb: > Tim schrieb: >> Warum ist das wichtig? Bei einigen Bootloadern kann u.U. eine >> Fehlfunktion auftreten, bei der der Speicher vor dem bootloader gelöscht >> und mit FFFF gefüllt ist. In diesem Fall sollte der Bootloader nach >> einem reset noch gestartet werden. > Es ist doch egal was vorm Bootloader im Flash steht! Wenn man einen > Bootloader verwendet, dann wird per FUSE die Startadresse des > Bootloaders eingestellt und nach dem Reset immer diese angesprungen. Dieses Feature unterstützen aber nur die ATMega. Auf den ATtiny gibt es keinen geschützten Bootloaderbereich und der Resetvektor liegt immer bei 0000.
Bei Micronucleus (Beitrag "Micronucleus - USB-Bootloader für ATtiny") wird das Problem gelöst, in dem erst der Speicher von hinten nach vorne gelöscht wird und danach wieder von vorne nach Hinten beschrieben wird. Damit ist zu jedem Zeitpunkt sichergestellt, dass entweder ein funktionierender Resetvektor vorhanden ist, oder der Speicher mit FFFF gefüllt ist. Im letzteren Falle "rutscht" die CPU einfach bis zum Bootloader durch. Letzteres funktioniert auch stabil und zuverlässig, allerdings bin ich durch eine Diskussion letztens etwas ins Stützen gekommen, ob da NOP oder SBRS ausgeführt wird. Ich habe eben mal nachgeschaut - Fastboot (Beitrag "UART Bootloader ATtiny13 - ATmega644") arbeitet nach dem gleichen Prinzip. Bei vielen anderen Bootloadern wird erst der Flashbuffer geladen und dann eine Erase/Write-Operation ausgeführt. Das ist von der Implementation her einfacher, birgt aber bei einem Abbruch das Risiko, dass die erste Seite gelöscht (FFFF) und der Rest des Speichers mit Programmfragmenten gefüllt ist. In dem Fall: Pech, dann ist der Bootloader tot.
Tim schrieb: > In dem Fall: Pech, dann ist der > Bootloader tot. In USBaspLoader (https://github.com/baerwolf/USBaspLoader/tree/testing) lass ich gar nicht erst Zugriffe auf die Bootloaderseiten zu. Die Daten selbst werden page-by-page geschrieben. In der aeusseren Schaltung empfehle ich ausreichend Kapazitaet (der Kondensatoren), sodass zusammen mit eingestellter Brown-Out detection dem AVR immer genug Zeit zum Beenden des Writecycles bleiben sollte. (Die gespeicherte Energie kann benutzt werden um Schreiben zu beenden, der Brownout verhindert weitere Codeausfuehrung - es wird keine neue Seite "angefangen".) In meinem neuen Bootloader fuer mein frisches Projekt (http://matrixstorm.com/avr/avrstick/) nutze ich das Erase-and-Write Feature der neueren AVRs. Pageerase und Pagewrite sind dann atomar. Auch hier ist natuerlich ausreichend Ladungspuffer und Brownout vorhanden. Achja, Nachtrag: In den default-Einstellungen lasse ich den Bootloader explizite page-erases ignorieren. (Das wird beim Schreiben on-demand erledigt.) MfG
Stephan B. schrieb: > Tim schrieb: >> In dem Fall: Pech, dann ist der >> Bootloader tot. > > In USBaspLoader (https://github.com/baerwolf/USBaspLoader/tree/testing) > lass ich gar nicht erst Zugriffe auf die Bootloaderseiten zu. > Die Daten selbst werden page-by-page geschrieben. Ja, da hast Du es bei den ATMegas mit dem geschützten Bereich und Bootvektor aber auch einfacher. Bei den ATtinies geht das nicht... > In der aeusseren Schaltung empfehle ich ausreichend Kapazitaet (der > Kondensatoren), sodass zusammen mit eingestellter Brown-Out detection > dem AVR immer genug Zeit zum Beenden des Writecycles bleiben sollte. > (Die gespeicherte Energie kann benutzt werden um Schreiben zu beenden, > der Brownout verhindert weitere Codeausfuehrung - es wird keine neue > Seite "angefangen".) Wird bei einem Brown-Out Reset denn die Seite auch fertig geschrieben? Das Manual schweigt sich dazu aus. > In meinem neuen Bootloader fuer mein frisches Projekt > (http://matrixstorm.com/avr/avrstick/) nutze ich das Erase-and-Write > Feature der neueren AVRs. > Pageerase und Pagewrite sind dann atomar. Auch hier ist natuerlich > ausreichend Ladungspuffer und Brownout vorhanden. Schick! Nur leider kann man das auch nur verwenden, wenn die Hardware die Funktion bietet :)
Tim schrieb: > Ja, da hast Du es bei den ATMegas mit dem geschützten Bereich und > Bootvektor aber auch einfacher. Bei den ATtinies geht das nicht... Prinzipiell empfehle ich diese spezielle Verwendung der Lockbits NICHT. (Also das hardwareseitige sperren der BLS.) Simpler Grund: Man kann keine Updates per Bootloader einspielen. Es gabs sogar mal hier im Forum den Fall das eine Firma, die einen BUG in deren Bootloader hatte, anfrage ob man das dann dennoch irgendwie machen kann. Das Ende war wohl, dass sie alle Geraete beim Nutzer rueckrufen mussten. Man kann durch ein einfaches "if" (pageaddr >= bootloader_page_addr) die gleiche funktion viel flexibler implementieren. Tim schrieb: > Wird bei einem Brown-Out Reset denn die Seite auch fertig geschrieben? > Das Manual schweigt sich dazu aus. Aus der Funktionsweise von Flash: Wenn die integrierte Sub-Schaltung "angeschubbst" wurde, dann brauchst Sie doch nur noch Energie und Zeit. Es muesste nach dem triggern also unabhaengig vom Reset sein. (Ich hatte auch noch nie Probleme bemerkt.) Natuerlich hat man beim konventionellen AVR immer noch min. 2 Opcodes zwischen Erase und Write. Da sollte der Brown-Out dann besser nicht zuschlage. (Das ist aber auch extrem unwahrscheinlich.) Tim schrieb: > Schick! Nur leider kann man das auch nur verwenden, wenn die Hardware > die Funktion bietet :) Ja, leider ;-) Vielliecht ein Trost: Auch einige aeltere AVRs implementieren Sie, obwohl nicht dokumentiert. MfG
> Tim schrieb: >> Wird bei einem Brown-Out Reset denn die Seite auch fertig geschrieben? >> Das Manual schweigt sich dazu aus. > > Aus der Funktionsweise von Flash: Wenn die integrierte Sub-Schaltung > "angeschubbst" wurde, dann brauchst Sie doch nur noch Energie und Zeit. > Es muesste nach dem triggern also unabhaengig vom Reset sein. (Ich hatte > auch noch nie Probleme bemerkt.) Also eine allgemeingültige Beschreibung der Funktionsweise von Flash ist das nicht. Zunächst einmal wird einfach eine hohe Spannung über den Stack mit Floating-Gate angelegt. Wobei es hier in der Implementierung des embedded Flash eine Menge unterschiedlicher Devicekonfigurationen gibt. Die Spannung wird mit einer Ladungspumpe erzeugt. Das ganze wird über einen Timer gesteuert, der bei vielen AVR vom internen RC-Oscillator abgeleitet wird. Wenn nicht mehr genug Spannung vorhanden ist, wird die Ladungspumpe vermutlich relativ schnell dicht machen, da es sich um high-Vt Devices handelt. Außerdem könnte der Brown-Out reset durchaus Timer, RC-Oscillator und Ladungspumpe resetten. Kurz: Ohne klare Spezifikation kann man von nix ausgehen. Die Eintretenswahrscheinlich ist aufgrund des kurzen Zeitraums zwischen Erase und Write allerdings wirklich recht gering. Als Safe-by-Design geht das aber nicht durch und mit so etwas würde man sich bei einem sicherheitsrelevanten Produkt in einer FMEA jede Menge Folgeaktivitäten einhandeln. Naja, ist auch egal. Für den Anwendungsbereich ist es sicherlich ausreichend :) Man kann sich ja auch jeden Router beim Firmware-Update auf die gleiche Art schrotten. Ich werde aber nicht auf eine integrierte Erase/Write-Architektur gehen.
Tim schrieb: >> In USBaspLoader (https://github.com/baerwolf/USBaspLoader/tree/testing) Hast Du Dir eigentlich diesen mal angeschaut? https://github.com/gblargg/usbasploader
Tim schrieb: > Hast Du Dir eigentlich diesen mal angeschaut? > > https://github.com/gblargg/usbasploader Nein, kannte ich noch nicht - Danke dir! Der Herr Green hatte auch nie was gesagt. Waere vielleicht toll gewesen sich zu "teamen", naja... (...Leider hat er Kompatibilitaet zwischen den Loadern gebrochen ;-(, waere sicherlich lustig gewesen mal kurz per Update seinen Bootloader zu testen...) Er hat viele Ideen fuer USBaspLoader 2.0 aufgegriffen - ggf. kommt das Release dann doch noch dieses Jahr ;-) MfG Stephan
Tim schrieb: > Kurz: Ohne klare Spezifikation kann man von nix ausgehen. Die > Eintretenswahrscheinlich ist aufgrund des kurzen Zeitraums zwischen > Erase und Write allerdings wirklich recht gering. Habe es im Manual gefunden: "Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can be done by enabling the internal Brown-out Detector (BOD) if the operating voltage matches the detection level. If not, an external low VCC reset protection circuit can be used. If a reset occurs while a write operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient" Die Schreiboperation wird also tatsächlich nicht durch den BOD unterbrochen.
Tim schrieb: > Die Schreiboperation wird also tatsächlich nicht durch den BOD > unterbrochen. Ui, danke dir fuer den Quellennachweis. Ich hatte es im Bauchgefuehl - Quelle ist natuerlich perfekt. MfG Stephan
Stephan B. schrieb: > Der Herr Green hatte auch nie was gesagt. Waere vielleicht toll gewesen > sich zu "teamen", naja... > > (...Leider hat er Kompatibilitaet zwischen den Loadern gebrochen ;-(, > waere sicherlich lustig gewesen mal kurz per Update seinen Bootloader zu > testen...) Warum? Eigentlich müsste das Update.hex doch funktionieren?
Tim schrieb: > Warum? Eigentlich müsste das Update.hex doch funktionieren? Er hat das Interface der SPM funktion komplett geaendert. Die Daten werden u.A. in anderen Registern uebergeben... ...Schade! (Ich hatte mir damals darueber extra Gedanken gemacht...) MfG
Thread beobachten
Seitenaufteilung abschaltenBitte 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.