|
Anzeige
|
STM32 UART Boot Loader überschreibt ohne löschen?
Gast
#5087252
Mahlzeit! weiss zufällig jemand, was der eingebaute Boot Loader macht, wenn man einen Sektor mehrmals beschreibt ohne ihn vorher zu löschen? Also, ich habe in einen neuen Chip ein Programm geflasht und das läuft auch. Dann habe ich ca. 2 Byte geändert und das Programm noch mal geflasht, aber vergessen, vorher zu löschen. Ist der Boot Loader schlau genug, die unveränderten Bytes zu überspringen oder habe ich den Chip geschrottet?
Gast
#5087294
normalerweise sind alle bits = 1 und werden (bei bedarf) auf 0 gebrannt. Solange kein Bit von 0 auf 1 wechseln muss, kannst Du drüberbrennen so oft Du willst. Der Bootloader muss daran garnichts machen.
Gast
#5087301
Nicht unbedingt, bei manchen Flash-Zellen ist das nicht erlaubt bzw. reduziert die Lebensdauer. eagle user schrieb: > Ist der Boot Loader schlau > genug, die unveränderten Bytes zu überspringen oder habe ich den Chip > geschrottet? Geschrottet wohl kaum. Achim S. schrieb: > normalerweise sind alle bits = 1 und werden (bei bedarf) auf 0 gebrannt. > > Solange kein Bit von 0 auf 1 wechseln muss, kannst Du drüberbrennen so > oft Du willst. Bei den F4 ist das (zum Teil?) so, siehe z.B. Kapitel 3.6.4 in RM0090 (S.86) für F407. Bei den F1 geht schreiben immer nur 16bit-weise und wenn diese 16bit nicht 0xFFFF sind verweigert er die Schreiboperation und setzt das PGERR bit im FLASH_SR (S.25 im Flash Programming Manual - PM0075). eagle user schrieb: > weiss zufällig jemand, was der eingebaute Boot Loader macht, wenn man > einen Sektor mehrmals beschreibt ohne ihn vorher zu löschen? Entweder kann er schreiben und sendet nach erfolgtem Schreibvorgang ein ACK oder er kann nicht schreiben und sendet ein NACK (S.18 AN3155). Da ich mal davon ausgehe, dass du irgendein PC-Programm mit dem UART-Bootloader nutzt, ist dann die Frage was das PC-Programm mit einem NACK macht. Entweder es bricht den Vorgang ab und gibt eine Fehlermeldung zurück oder es beschließt den Sektor zu löschen und es nochmal zu versuchen. stm32flash prüft dann z.B. auch am Ende ob der Flashvorgang korrekt durchgeführt wurde. eagle user schrieb: > Nicht unbedingt, bei manchen Flash-Zellen ist das nicht erlaubt bzw. > reduziert die Lebensdauer. Und welche sollen das sein? Nachtrag: Habe mal interessehalber nachgeschaut wie es bei den anderen STM32 wegen Bit-weiser Flash-Programmierung aussieht. Bei F0 und F3 scheint es so zu sein wie bei F1, also 16bit und nur schreibbar wenn 0xFFFF, allerdings mit dem Zusatz, dass ein 0x0000 immer schreibbar ist. Beim L0 und L1 gehen nur 32bit auf einmal und beim L4 64bit, wobei bei allen das ECC vom Flash der Grund sein dürfte warum man keine einzelnen Bits brennen kann bzw. sollte. Beim F7 scheint es wie beim F4, d.h. einzelne Bits sind manipulierbar, so lange man nicht versucht aus einer 0 eine 1 zu machen.
Gast
#5087967
Beim F205 (im PM0059) heisst es:
Und genau das ist hier wohl passiert, d.h. der Boot Loader schreibt ein Wort auch mehrmals. Mit OTP-EPROMs hat mir der Trick schon mal ein paar Chips gerettet, aber ich dachte, bei Flash macht man sowas nicht. Mal angenommen, für eine Null wird ein isoliertes Gate aufgeladen. Dann wird es beim Überschreiben irgendwann überladen - das kann nicht gesund sein. Aber dank eurer Forschungsarbeit gehe ich jetzt mal davon aus, dass mein F205 das Überschreiben verträgt und es bei anderen Chips von der Hardware ggf. verhindert wird. Dankeschön! Meine Panik kam daher, dass es "plötzlich" einen CRC-Fehler gab, aber das ist geklärt. Ein Bit-für-Bit Vergleich vom Flash-Inhalt liefert keinen Beweis, aber starke Indizien: das eigentliche Program ist unverändert, von den 32 CRC-Bits stehen nur noch 4 auf Eins und ein Zeitstempel sagt, die Änderung passierte, während ich unterwegs zum Baggersee war :) Und das alles wegen einer kosmetischen Änderung von einem Datentyp, der in dem Programm garnicht benutzt wird. Aber ein Headerfile ist neu und also muss neu gebaut werden... Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
