Schreibfehler bei Bootloader auf ARM

Geri schrieb:
> Hallo zusammen
>
> Nehmen wir an, man hat einen Bootloader, welcher eine Applikation auf
> den selben Controller (STM32F103) schreibt.
>
> Nehmen wir an, es kommt bei der Programmierung einer Flash-Zellen zu
> einem Spannungsausfall. Könnte es sein, dass dabei eine falsche
> Speicherzelle beschrieben und der Bootloader zerstört wird.
>
> Alle Interrupts ausgeschaltet.
>
> ..oder sind euch andere Gründe bekannt, wann so ein

Theoretisch hast dur recht, und auch praktisch ist mir für STM32 kein 
Fall bekannt.

Praktisch hatte ich bei anderen µC diesen Fall aber schon gehabt. 
Inklusive toter Devices. Da war der Bootloader tot, oder es waren 
Abgleichwerte überschrieben. Das passierte beim Brown-Out oder beim 
Einschalten. Und ja, da wurde "erfolgreich" in gesperrte 
Speicherbereiche geschrieben, meist in Form von Müll.

Wichtig ist also eine saubere Behandlung von Unterspannung, dafür hat 
der STM32 einen internen POR (Reset), den man also unbedingt einschalten 
sollte.
Die Einschränkungen der Spannungsrampe beim Einschalten sollte man auch 
beachten (falls vorhanden), auch da passieren solche Dinge.

Hat man das getan, muss man eigentlich keine Angst haben, dass das 
passiert.

Name: schrieb:
> Wichtig ist also eine saubere Behandlung von Unterspannung, dafür hat
> der STM32 einen internen POR (Reset), den man also unbedingt einschalten
> sollte.

Schadet nicht, aber auch ohne kann man nichts zerschießen. Wir testeten 
das bei einem STM32F051 mit einem programmierbarem Netzteil. Ergebnis: 
auch nach 50 Programmierabbrüchen wegen unterbrochener 
Spannungsversorgung war ein erneutes Programmieren mit dem Bootloader 
ohne Einschränkung möglich. Zurückgelesen wurde ebenfalls ein korrektes 
HEX-File.

Vielen Dank für eure Meinungen und Tipps!

Ich meinte nicht den integrierten sondern einen eigenen Bootloader.


Euren Ausführungen zu folgen, dann müsste es also zu 100 % ausreichend 
sein, wenn man die Pages in denen der Bootloader platziert ist durch 
Setzen der "WRPx: Flash memory write protection option bytes" schützt.


Brown-Out wäre dann zusätzlich noch sinnvoll, um unerwünschtes Verhalten 
der Applikation bei Spannungseinbrüchen zu verhindern.


Stimmts:)?

Beste Grüße und Danke nochmals

Geri

Es kann auch passieren das bei einem Spannungseinbruch der BL einen 
falschen Wert bekommt den er dann in den Speicher schreibt. Sollte der 
BL die Möglichkeit haben auf sich selbst zu schreiben, so kann eine 
falsche Adressierung dies bewirken. Deshalbt sollte man die Fúses 
passend setzen. Bei AVR geht das auch extra, so dass man nicht mal den 
BL lesen kann. Beim STM weis ich aber die Fusenamen nicht

@Jim: Danke auch ein coole Idee!

Also nehmen wir an, der Bootloader wird durch code protection geschützt, 
dann kann lediglich beim Flashen der Applikation etwas schief gehen. Der 
Bootloader ist aber nicht betroffen. Man wäre dann ja auf der sicheren 
Seite.


Was passiert aber wenn der Bootloder nicht geschützt wäre und er bei 
einem STM32F103 bzw. ARM32 abgeschossen wird? Könnte das dazu führen, 
dass beim Startup irgendein Code im Flash angesprungen wird oder sind 
beim ARM bzw. bei STM32F103-Controller bereits Schutzmechanismen 
vorhanden?


Bzgl. der Fuses und Brown out detect: Wenn man am Controller einen 
Supervisor-Chip am NRST-Eingang (Pin 25) anschließt z.B. einen Max809 
o.ä. Erübrigt sich dann eigentlich das Aktivieren der Brown-out 
detection und evtl. Power on reset o.ä.?
..doppelt gemoppelt:)?

Wenn der Bootloader kaputt ist, ist jedes Fehlverhalten denkbar.

Zu deiner zweiten Frage: Natürlich braucht man nicht zweimal die gleiche 
Funktion zur Spannungsüberwachung.