Forum: Mikrocontroller und Digitale Elektronik STM32 UART Boot Loader überschreibt ohne löschen?


von eagle user (Gast)


Lesenswert?

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?

von A. S. (Gast)


Lesenswert?

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.

von eagle user (Gast)


Lesenswert?

Nicht unbedingt, bei manchen Flash-Zellen ist das nicht erlaubt bzw. 
reduziert die Lebensdauer.

von Christopher J. (christopher_j23)


Lesenswert?

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?

von Christopher J. (christopher_j23)


Lesenswert?

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.

von eagle user (Gast)


Lesenswert?

Beim F205 (im PM0059) heisst es:
1
Successive write operations are possible without the need
2
of an erase operation when changing bits from ‘1’ to ‘0’.
3
Writing ‘1’ requires a Flash memory erase operation.
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...

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