Speichern beim STM32 ins Flash

[Frank (Gast)]

Hallo,
wird beim Abspeichern einer Variable in den Flash-Speicher jeweils nur 
ein einziges Byte weggeschrieben oder wird immer ein ganzer Block (ggf. 
wie groß?) neu beschrieben?

[J. V. (janvi)]

Im Flash kann immer nur ein ganzer Block gelöscht werden und das 
Schreiben geht nur in einer Richtung. Es gibt Code zur Eeprom Simulation 
im Flash welcher ein Wear Leveling macht und die benutzten 
Speicherstellen gleichmässig verteilt. Hierzu wird immer eine virtuelle 
Adresse und die dazugehörenden Daten (irgendwo passend mithilfe eines 
Verzeichnisses) gespeichert. Siehe Application notes...

Der STM32L1x hat echtes Eeprom welches Wortweise beschrieben werden 
kann.

[Frank (Gast)]

Das heißt, ich lösche einen ganzen Block und kann ihn dann Byte für Byte 
wieder neu beschreiben?

[dummschwaetzer (Gast)]

ja.
hat ST im Cube-MX auch Demo-Apps.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Frank schrieb:
> Das heißt, ich lösche einen ganzen Block und kann ihn dann Byte für Byte
> wieder neu beschreiben?
Das haengt from STM32 ab. F1 schreibt 2 Bytes, F4 kann auch 1 Byte, L4 
nur 8 Byte ... auf einmal

[Markus M. (adrock)]

Löschen kann man nur jeweils eine ganze Flash-Page, schreiben kann man 
allerdings in Blöcken von z.B. 8 Bytes (STM32G0x).

Man kann es so programmieren, dass man immer Werte innerhalb einer Page 
"hinten" anhängt, bis die Page voll ist. Dann löscht man die ganze Page 
und fängt von vorne an.

Wie voll eine Page ist kann man erkennen ab wo nur noch 0xff Bytes 
kommen (der Zustand nach dem Löschen der Page).

Wenn man Daten verschiedener Längen im Flash speichern will, kann man in 
das erste Wort jeweils noch die Länge der folgenden Daten schreiben, 
dann kann man sich anhand dieser Werte schnell zum Ende der "Liste" 
hangeln und weiß wo man weiter schreiben kann.

Steht dann an dieser Stelle ein "0xffffffff", weiß man dass man am Ende 
ist.

[Schwanzus Kurzus (Gast)]

Also sich auf ein Bitmuster zu verlassen geht doch gar nicht. Das können 
auch immer reguläre Nutzdaten ein. Da muß man schon einen separaten 
Positionszeiger spendieren, wenn es zuverlässig sein soll.

[Klaus W. (mfgkw)]

Schwanzus Kurzus schrieb:
> Da muß man schon einen separaten
> Positionszeiger spendieren

Und den speicherst du wo?
Der ändert sich ja bei jedem Schreiben.

[Schwanzus Kurzus (Gast)]

Volatile im Battery-Backup-RAM? Wenn der Chip keins hat: Designfehler. 
Wenn tatsächlich abgeschaltet wird, muß der natürlich selbst im Flash 
gespeichert werden. Oder gleich ein kleines FRAM nehmen.

[Markus M. (adrock)]

Schwanzus Kurzus schrieb:
> Also sich auf ein Bitmuster zu verlassen geht doch gar nicht. Das können
> auch immer reguläre Nutzdaten ein. Da muß man schon einen separaten
> Positionszeiger spendieren, wenn es zuverlässig sein soll.

Das mit dem Bitmuster geht schon so. Da es (bei meiner Implementierung) 
die oben erwähnte Längenangabe ist, kann diese niemals 0xffffffff sein.

-1/0xffffffff als einen speziellen Wert zu verwenden wird bei vielen 
Funktionen im Unix-Umfeld gemacht.

Natürlich muss man schon noch den Fall abfangen, dass es evtl. einen 
Lesefehler im Flash geben kann. Man könnte als erstes Wort z.B. auch 
noch eine Prüfsumme hinzufügen.

[NichtWichtig (Gast)]

Schwanzus Kurzus schrieb:
> Volatile im Battery-Backup-RAM? Wenn der Chip keins hat: Designfehler.
> Wenn tatsächlich abgeschaltet wird, muß der natürlich selbst im Flash
> gespeichert werden. Oder gleich ein kleines FRAM nehmen.

Es gibt jede Menge Einsatzgebiete wo Batterien verboten sind. Erzeugen 
nur lästigen Serviceaufwand.

Und natürlich kann man 0xffffffff als gelöschte Speicherzelle hernehmen, 
da braucht es keine separaten Positionspointer.

Allerdings wäre eine Checksum im gespeicherten Datensatz nicht schlecht.

[Cyblord -. (cyblord)]

Klaus W. schrieb:
> Und den speicherst du wo?
> Der ändert sich ja bei jedem Schreiben.

Deshalb wurden Dateisysteme erfunden. Es gibt da auch sehr einfache 
Ansätze, ohne Verzeichnisse usw.

[c-hater (Gast)]

NichtWichtig schrieb:

> Schwanzus Kurzus schrieb:
>> Oder gleich ein kleines FRAM nehmen.
>
> Es gibt jede Menge Einsatzgebiete wo Batterien verboten sind. Erzeugen
> nur lästigen Serviceaufwand.

Tja, genau deswegen wurde wohl FRAM erfunden, die brauchen keine 
Batterien...

Du scheinst davon noch nicht einmal gehört zu haben...

[NichtWichtig (Gast)]

c-hater schrieb:
> NichtWichtig schrieb:
>
>> Schwanzus Kurzus schrieb:
>>> Oder gleich ein kleines FRAM nehmen.
>>
>> Es gibt jede Menge Einsatzgebiete wo Batterien verboten sind. Erzeugen
>> nur lästigen Serviceaufwand.
>
> Tja, genau deswegen wurde wohl FRAM erfunden, die brauchen keine
> Batterien...
>
> Du scheinst davon noch nicht einmal gehört zu haben...

Das Vorhandensein solcher Bausteine ändert nichts an meiner Aussage.