EDAboard.com | EDAboard.de | EDAboard.co.uk | EE World

STM32FXX Flash Speicher weniger abnutzen

NEUES THEMA

elektroda.net NewsGroups Forum Index - Electronics DE - STM32FXX Flash Speicher weniger abnutzen

Goto page 1, 2, 3  Next

Ole Jansen
Guest

Wed Feb 12, 2020 3:45 pm   



Moin,

Für deinen STM32F107 Connectivity Line möchte ich einen nicht
flüchtigen Ereigniszähler implementieren und das interne Flash Memory
benutzen. Ich benötige lediglich eine Routine welche die Zahl der
Ereignisse zurückgibt und eine Andere welche die Anzahl der Ereignisse
um 1 erhöht.

Der Chip hat in seinem Flash Speicherseiten mit 2048 bytes die als
Ganzes gelöscht werden können (danach sind alle bytes 0xFF) und die
mitgelieferte Bibliothek verwendet fürs Schreiben einer Zelle
jeweils ein word mit 2 byte.

Für die Speicherung von Parametern gibt es von ST eine
EEPROM-Simulation die hier beschrieben ist und etwa 4 byte
Flashspeicher bei jedem Schreibzugriff für die Aktualisierung eines
Parameters neu beschreibt:

<https://www.st.com/content/ccc/resource/technical/document/application_note/ee/ef/d7/87/cb/b7/48/52/CD00165693.pdf/files/CD00165693.pdf/jcr:content/translations/en.CD00165693.pdf>

Die Anzahl der Ereignisse so hoch dass ich Bedenken hätte dass
die Abnutzung des Flashspeichers zu hoch wird (Etwa Faktor 40).
Daher die Frage:

- Ist es möglich bei dem Chip einzelne bytes zu schreiben?

- Es es u.U sogar möglich in bereits beschriebene Speicherzellen
zu schreiben? z.B. ein bit nach dem Anderen löschen
( 0XFF, 0XFE, 0XFC ... 0X00)?

Kennt jemand den Chip oder die Funktionsweise des internen
Flash etwas genauer oder hat einen anderen Tip?

Danke und viele Grüße,

O.J.

Andreas Fecht
Guest

Wed Feb 12, 2020 4:45 pm   



Am 12.02.2020 um 14:53 schrieb Ole Jansen:
Quote:

Die Anzahl der Ereignisse so hoch dass ich Bedenken hätte dass
die Abnutzung  des Flashspeichers zu hoch wird (Etwa Faktor 40).
Daher die Frage:

- Ist es möglich bei dem Chip einzelne bytes zu schreiben?

- Es es u.U sogar möglich in bereits beschriebene Speicherzellen
  zu schreiben? z.B. ein bit nach dem Anderen löschen
  ( 0XFF, 0XFE, 0XFC ... 0X00)?

Kennt jemand den Chip oder die Funktionsweise des internen
Flash etwas genauer oder hat einen anderen Tip?


Das geht, das habe ich für einen Betriebsstundenzähler auch schon gemacht.

Mann kann bei den einfachen STM-Typen jedes Bit einzeln setzen. Löschen
kann man jedoch nur die gesamte Page.

Man muss aber aufpassen, falls der Controller eine ECC-Korrektur hat,
dann gehts nicht. Dann kann man ein ganzes Wort nur komplett setzten.
Wort kann hier auch 64-Bit auf einmal bedeuten. Die schnelleren
32-Bit-Typen haben oft ein 64-Bit-Flash-Interface. Datenblatt befragen!

Die Bits der Flash-Page können je nach Typ nach dem Löschen alle auf 1
oder 0 sein.

Gruß Andreas

Uwe Bonnes
Guest

Wed Feb 12, 2020 9:45 pm   



Ole Jansen <remove.this.kaspernasebaer_at_gmx.de> wrote:
Quote:
Moin,

Für deinen STM32F107 Connectivity Line möchte ich einen nicht
...

- Ist es möglich bei dem Chip einzelne bytes zu schreiben?


Bei STM32F1 werden immer Worte geschrieben

Quote:

- Es es u.U sogar möglich in bereits beschriebene Speicherzellen
zu schreiben? z.B. ein bit nach dem Anderen löschen
( 0XFF, 0XFE, 0XFC ... 0X00)?


0xffff erhaelst Du mit Page Erase. Danach kannst du Bit nur noch nach
Null schreiben. Das aber auch in vielen verschiedenen
Schreibvorgaenngen .

Quote:

Kennt jemand den Chip oder die Funktionsweise des internen
Flash etwas genauer oder hat einen anderen Tip?

Was spricht gegen die Art und Weise wie ST das implementier?
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

Marte Schwarz
Guest

Thu Feb 13, 2020 8:45 am   



Hi Ole,

Quote:
Für deinen  STM32F107 Connectivity Line möchte ich einen nicht
flüchtigen Ereigniszähler implementieren und das interne Flash Memory
benutzen.


Kommt eben drauf an, wie oft man solche Schreibvorgänge vor hat.

Quote:
mitgelieferte Bibliothek verwendet fürs Schreiben einer Zelle
jeweils ein word mit 2 byte.


Eher 4 bei einem 32 Bit µC

Quote:
Für die Speicherung von Parametern gibt es von ST eine
EEPROM-Simulation die hier beschrieben ist und etwa 4 byte
Flashspeicher bei jedem Schreibzugriff für die Aktualisierung eines
Parameters neu beschreibt:


klingt logisch

Quote:
Die Anzahl der Ereignisse so hoch dass ich Bedenken hätte dass
die Abnutzung  des Flashspeichers zu hoch wird (Etwa Faktor 40).
Daher die Frage:

- Ist es möglich bei dem Chip einzelne bytes zu schreiben?


Nein

Quote:
- Es es u.U sogar möglich in bereits beschriebene Speicherzellen
  zu schreiben? z.B. ein bit nach dem Anderen löschen
  ( 0XFF, 0XFE, 0XFC ... 0X00)?


Das müsste sogar gehen

Quote:
Kennt jemand den Chip oder die Funktionsweise des internen
Flash etwas genauer oder hat einen anderen Tip?


Ein kleines serielles EEProm. Die sind genau dafür da.
Alternativ wäre noch ein Batteriebackup bzw Goldcap und erst ins Flash
schreiben, wenn die Spannungsversorgung zusammenbricht.

Marte

Ole Jansen
Guest

Thu Feb 13, 2020 9:45 am   



Moin,

Am 12.02.2020 um 16:27 schrieb Andreas Fecht:
Quote:
Am 12.02.2020 um 14:53 schrieb Ole Jansen:

Die Anzahl der Ereignisse so hoch dass ich Bedenken hätte dass
die Abnutzung  des Flashspeichers zu hoch wird (Etwa Faktor 40).
Daher die Frage:



Das geht, das habe ich für einen Betriebsstundenzähler auch schon gemacht


Vermutlich wird sowas ja öfter verlangt.

Quote:
Mann kann bei den einfachen STM-Typen jedes Bit einzeln setzen. Löschen
kann man jedoch nur die gesamte Page.


Das war meine Hoffnung. Mein erster Versuch mit
Sourcery G++ Lite for ARM EABI war allerdings bislang nicht
erfolgreich.

Ich verwende die Bibliothek stm32f10x_flash.c und wenn
ich die Routinen FLASH_ProgramHalfWord (16bit) oder
FLASH_ProgramWord(32bit) auf eine bereits beschriebene Adresse
benutze benutze gibt die Funktion einen Fehler zurück und
der Speicherinhalt ändert sich nicht.

Quote:
Man muss aber aufpassen, falls der Controller eine ECC-Korrektur hat,
dann gehts nicht. Dann kann man ein ganzes Wort nur komplett setzten.


Weiss ich ehrlich gesagt nicht.

Ich muss gestehen dass ich mich beim Durcharbeiten der Datenblätter
etwas schwer tue. Es gibt so viele Varianten von dem Chip.
Kann man ihn vielleicht einfach selber fragen?

Die Funktion FLASH_ProgramHalfWord macht jedenfalls grob Folgendes:

// if the previous operation is completed, proceed to program the
// new data:

FLASH->CR |= CR_PG_Set;

*(__IO uint16_t*)Address = Data;

//Wait for last operation to be completed
status = FLASH_WaitForLastOperation(ProgramTimeout);

// Disable the PG Bit
FLASH->CR &= CR_PG_Reset;

Falls es eine ECC Korrektur gibt ist die nicht in der Software.

Quote:
Wort kann hier auch 64-Bit auf einmal bedeuten. Die schnelleren
32-Bit-Typen haben oft ein 64-Bit-Flash-Interface. Datenblatt befragen!


Mein Muster hier kann 16bit oder 32bit usw. Wenn sich Footprint
und Pinning nicht ändern könnte ich jetzt ggf. auch noch einen anderen
Typ auswählen. Plan B wäre stumpf für jedes Inkrement 16
Nullen in die Speicherzellen zu schreiben und einen Chip mit
entsprechend viel Flash zu nehmen. 40k Flash Speicher für einen
"Betriebsstundenzähler" aufzuwenden ist heutzutage ja möglich
aber ich fände es trotzdem häßlich.

Quote:
Die Bits der Flash-Page können je nach Typ nach dem Löschen alle auf 1
oder 0 sein.


Hier sind sie 0xFF, also 1. Wobei das auch sein kann dass der Speicher
physikalisch anders organisiert ist. War jetzt nicht so wichtig für
mein Problem, ich bin bloß neugierig bzw. möchte meinen Code möglichst
gut portierbar schreiben.

Viele Grüße,

O.J.

Andreas Fecht
Guest

Thu Feb 13, 2020 11:45 am   



Am 13.02.2020 um 08:54 schrieb Ole Jansen:

Quote:
Mein Muster hier kann 16bit oder 32bit usw. Wenn sich Footprint
und Pinning nicht ändern könnte ich jetzt ggf. auch noch einen anderen
Typ auswählen. Plan B wäre stumpf für jedes Inkrement 16
Nullen in die Speicherzellen zu schreiben und einen Chip mit
entsprechend viel Flash zu nehmen. 40k Flash Speicher für einen
"Betriebsstundenzähler" aufzuwenden ist heutzutage ja möglich
aber ich fände es trotzdem häßlich.


So viel Speicher muss man für einen Zähler nicht verschwenden.
Bei mir genügen 2-3 Pages. Bei einer Page mit 2048 Bytes kann man bei
bitweiser Ansteuerung bis zu 16384 zählen mit nur einmal löschen. Den
Übertrag zählt man dann in der nächsten Page. Bei 10k erlaubten
Löschvorgängen zerstört sich das Ding nach 163Mio Zählvorgängen.

Wenn man mehrere Pages für das "LSB" verwendet, erhöht sich der Wert bei
jeder weiteren Page nochmal um 163Mio.

Wenn's nicht bitweise geht, verringert sich der Wert bei 32-Bit-Worten
um den Faktor 32. Das sind bei einer LSB-Page immer noch über 5Mio.

Ich habe das mit dem Keil realisiert und ich programmiere über den HAL.
Der ruft aber auch nur die FLASH_Program_xxxxxWord(); Funktion auf.

Getestet mit dem STM32L052 mit 1 bitweisem schreiben, bei einem
STM32L433 (mit ECC) nur 64 bitweise.

Was ich auch noch festgestellt habe:
Die Schreibadresse kann man nur in Vielfachen der Wortbreite des Flashs
angeben. Es sieht so aus als könnte man den Speicher byteweise
adressieren, bei krummen Adressen, die nicht auf die Busbreite des
Flashinterfaces matchen, hagelt es Fehler.

Gruß Andreas

Thorsten Böttcher
Guest

Thu Feb 13, 2020 12:45 pm   



Am 13.02.2020 um 08:54 schrieb Ole Jansen:

Quote:
Weiss ich ehrlich gesagt nicht.

Ich muss gestehen dass ich mich beim Durcharbeiten der Datenblätter
etwas schwer tue. Es gibt so viele Varianten von dem Chip.
Kann man ihn vielleicht einfach selber fragen?


Ja, man kann den Chip auch fragen, in irgendeinem Register steht das.
Oder der Programmer zeigt es an.

Aber noch einfacher ist es einfach den Aufrdruck auf dem IC zu lesen.
Interessant ist doch maximal der Typ und der Speicher. Die Anzahl der
Pins und die Bauform sieht man auch so.

Das Reference-Manual gilt aber für die gesamte Serie, da reicht es
erstmal grob den Typ zu wissen.

Rafael Deliano
Guest

Thu Feb 13, 2020 5:45 pm   



Wäre bei Flash skeptisch.

Aber Versuch mit einem IC im Dauerbetrieb das Zähler hochlaufen
lässt ist jedoch schnell gemacht. Typisch eben den Page-Erase
minimieren indem man die unteren Zähler-Bits als Bits in
Bytes/Words setzt. Testpin schalten damit man sieht wie lange
Operation dauert. Wahrscheinlich wird einem da schon übel.
Kältespray/Heissluft drauf.

Der andere Aspekt ist unkontrollierter power down. D.h. der
Benutzer schaltet Gerät nicht ordentlich ab. Er kann bei
laufendem Betrieb die Batterien herausnehmen oder den
Netzstecker ziehen.
Für den Fall ist Redundanz zur Fehlerkorrektur sinnvoll.
D.h. zwei Zähler, zwei Speicherseiten die wechselweise
geschrieben werden. Stimmen die Zähler mit höherem Wert
beim power up nicht überein, wird die andere alte,
hoffentlich undemolierte Speicherseite als Startwert
verwendet.

Ich würde externes serielles FRAM bevorzugen. FRAM schreibt
schneller als EEPROM/Flash.

Power down müsste man auf Breadboard per automatischer
Testschaltung prüfen. Gemischte HW/SW-Bugs brauchen
immer üppige Statistik.

MfG JRD

Volker Bartheld
Guest

Thu Feb 13, 2020 8:45 pm   



Servus!

On Wed, 12 Feb 2020 14:53:55 +0100, Ole Jansen wrote:
Quote:
Fr einen STM32F107 Connectivity Line mchte ich einen nicht flchtigen
Ereigniszhler implementieren und das interne Flash Memory benutzen. Ich
bentige lediglich eine Routine welche die Zahl der Ereignisse
zurckgibt und eine Andere welche die Anzahl der Ereignisse um 1 erhht.
Der Chip hat in seinem Flash Speicherseiten mit 2048 bytes die als
Ganzes gelscht werden knnen (danach sind alle bytes 0xFF) und die


Bentigst Du fr Deinen Ereigniszhler zwingend immer die vollen 256kB des
Flashspeichers oder hast Du sogar die Mglichkeit auf eine Variante
auszuweichen, die (nur) 64kB Flash und 64kB SRAM hat?

In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzursten,
sondern die Zhlerei im SRAM zu veranstalten und nur alle naslang genau
die notwendigen Daten von SRAM in den Flash zu bertragen. Natrlich mu
man sich das mit der Stromaufnahme und den Standbyzyklen genau berlegen
und auch Vorkehrungen fr den Brownout treffen, d. h. vielleicht einen
Goldcap verwenden und mittels Betriebsspannungsberwachung die Daten
wegschreiben, bevor dem Chip der Saft ausgeht.

Irgendwelche Magie mit Bitjongliererei macht die Sache nur unntig
kompliziert und fehleranfllig. Wie stellst Du Dir das vor? Die
Holzhammermethode, wo man den Speicher nicht in Words aufteilt, sondern
einfach einen Bandwurm von Bits mit Nullen fllt, 100 Nullen sind dann 100
Ereignisse, usw.?

Und: 256k Flash fr einen Ereigniszhler? Echt jetzt? 2^2097152 Ereignisse?
Wieviele Atome in wievielen Universen willst Du denn zhlen? Falls Du also
nicht den vollen Speicher bentigst, httest Du immer noch 20
Speicherseiten, ber die Du permutieren knntest (wenn sie sich nur als
Ganzes lschen lassen).

Auf die Schnelle habe ich im Datenblatt nur was von 10'000 Zyklen minimal
gelesen, d. h. 200'000 Ereignisse minimal, wenn man es nur halbwegs schlau
anstellt. Etwas schlauer schon wre der Kompromi, da es auf +/-x
Ereignisse nicht ankommt, dann knntest Du im SRAM zhlen und nur jedes
x-te Ereignis im Flash sichern. Dann wren im worst case (jemand zieht den
Stecker) eben x-1 Ereignisse vergessen, das Flash wrde aber im Gegenzug
x*200'000 Zyklen halten.

Ciao,
Volker

Ole Jansen
Guest

Fri Feb 14, 2020 8:45 am   



Hallo Volker,

Quote:
On Wed, 12 Feb 2020 14:53:55 +0100, Ole Jansen wrote:
Für einen STM32F107 Connectivity Line möchte ich einen nicht flüchtigen
Ereigniszähler implementieren und das interne Flash Memory benutzen. Ich
benötige lediglich eine Routine welche die Zahl der Ereignisse
zurückgibt und eine Andere welche die Anzahl der Ereignisse um 1 erhöht.
Der Chip hat in seinem Flash Speicherseiten mit 2048 bytes die als
Ganzes gelöscht werden können (danach sind alle bytes 0xFF) und die

Benötigst Du für Deinen Ereigniszähler zwingend immer die vollen 256kB des
Flashspeichers oder hast Du sogar die Möglichkeit auf eine Variante
auszuweichen, die (nur) 64kB Flash und 64kB SRAM hat?


Ganz so schlimm ist es glücklicherweise nicht.

Ich hole noch mal kurz aus:

Die "EEPROM Simulation" von ST verwendet zwei Speicherseiten
und setzt am Anfang der Seiten jeweils Flags welche Seite aktiv ist.
Bei den µC der Connectivity Line sind die Seiten 2048 bytes groß, bei
anderen Linien können die auch 1024 groß sein.
Die Routine schreibt Parameter weg indem eine definierte
"virtual adress" (16bit) gefolgt von dem Wert (16bit) an die
nächste freie Stelle geschrieben werden.

Wenn die Seite voll ist geht er die Liste mit den ihm
bekannten virtuellen Adressen durch, löscht die inaktive
Seite und kopiert alle gespeicherten Parameter dorthin
und setzt die Seite aktiv. Damit wird einerseits die
Abnutzung gleichmäßig verteilt, andererseits kann die Routine
Inkonsistenzen erkennen und ggf. alles auf den letzten
konsistenten Status zurücksetzen.

Angenommen also ich verwende 4096 byte Flash speicher,
schreibe 4 byte pro Update und erlaube 10000 Löschzyklen, dann
reichte das für grob 1e7 Ereignisse minus Verluste
durch Overhead/Kopieren anderer Parameter.
Erwartet werden worst case 4e8 Ereignisse.

> In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzurösten,

Wenn ich die Firmware rausrechne hätte ich noch ca. 40k soda Flash
Speicher die ich sinnlos kaputtrösten "darf". Sagen die Auditoren...

Ich bin bei sowas aber aber Ästhet und es könnte sein dass jemand
den Quellcode gegenliest der sich auskennt ;-)

Quote:
sondern die Zählerei im SRAM zu veranstalten und nur alle naslang genau
die notwendigen Daten von SRAM in den Flash zu übertragen.


Zur Zeit gibt es kein batteriegepuffertes RAM oder externes EEPROM.
Verlorene Ereignisse sind eher unerwünscht.

Quote:
Natürlich muß
man sich das mit der Stromaufnahme und den Standbyzyklen genau überlegen
und auch Vorkehrungen für den Brownout treffen


Ein verlorenes Ereignis bei Brownout o.Ä. wäre ggf noch akzeptabel.

Quote:
d. h. vielleicht einen
Goldcap verwenden und mittels Betriebsspannungsüberwachung die Daten
wegschreiben, bevor dem Chip der Saft ausgeht.


Das ist durchaus eine Alternative.

Quote:
Irgendwelche Magie mit Bitjongliererei macht die Sache nur unnötig
kompliziert und fehleranfällig. Wie stellst Du Dir das vor?


Ich verwende zwei Seiten. Inkremente werden in Word0 gespeichert
und ansonsten lösche ein bit nach dem Anderen.
Wenn das letzte bit der Seite gelöscht ist übertrage ich die Inkremente
auf word0 der anderen Seite analog zur EEPROM Simulation wie oben
beschrieben. Bei 10000 Löschzyklen könnte das für 3.2e8 Ereignisse
mit zwei Speicherseiten ausreichen.

> Und: 256k Flash für einen Ereigniszähler? Echt jetzt? 2^2097152 Ereignisse?

Denk an Moores Gesetz. Der Markt schreit geradezu nach
ZFS und GigE auf embedded Devices für Heimautomation!elf

> Wieviele Atome in wievielen Universen willst Du denn zählen?

Alle!

Quote:
Etwas schlauer schon wäre der Kompromiß, daß es auf +/-x
Ereignisse nicht ankommt, dann könntest Du im SRAM zählen und nur jedes
x-te Ereignis im Flash sichern. Dann wären im worst case (jemand zieht den
Stecker) eben x-1 Ereignisse vergessen, das Flash würde aber im Gegenzug
x*200'000 Zyklen halten.


Die Lösung mit den 3.3e8 Könnte ich ggf. noch als ausreichend verkaufen
wenn man die 10000 nicht so eng sieht.

Der Code mit der Bitschubserei läuft im Emulator, aber nicht auf dem
echten Contoller. Ich vermute stark dass Andreas Recht hat und dass mein
µC wegen ECC ö.Ä. keine beschriebenen Worte im Flash überschreiben
will oder kann. Was z.B. auch bedeuten würde beim ersten Schreibfehler
gar keine weiteren Ereignisse gezählt würden.

Leider bin ich in den Datenblättern und AppNotes immer noch nicht
fündig geworden wo das genau beschrieben wird.

Viele Grüße,

O.J.

Ole Jansen
Guest

Fri Feb 14, 2020 9:45 am   



Am 13.02.2020 um 11:43 schrieb Andreas Fecht:
Quote:
Ich habe das mit dem Keil realisiert und ich programmiere über den HAL.
Der ruft aber auch nur die FLASH_Program_xxxxxWord(); Funktion auf.


Die zeigt bei mit folgendes Verhalten:
Sie gibt bei mir 0x04 bei Erfolg zurück und 0x02 wenn ich
in eine bereits beschriebene Zelle schreiben möchte.

- Dabei ist es egal ob ich in die Zelle den aktuellen
Inhalt zurückschreiben möchte oder was Anderes.
Ausnahme hiervon: 0xFFFF in eine Zelle schreiben
die 0xFFFF enthält gibt 0x04 zurück.

Quote:
Getestet mit dem STM32L052 mit 1 bitweisem schreiben, bei einem
STM32L433 (mit ECC) nur 64 bitweise.


ProgramHalfWord kann bei mir 16bit weise. Weniger geht anscheinend
nicht.

Quote:

Was ich auch noch festgestellt habe:
Die Schreibadresse kann man nur in Vielfachen der Wortbreite des Flashs
angeben.


OK.

Quote:
Es sieht so aus als könnte man den Speicher byteweise
adressieren, bei krummen Adressen, die nicht auf die Busbreite des
Flashinterfaces matchen, hagelt es Fehler.


Hab ich noch nicht probiert.

AFAIK ist mein µC Litte Endian.

Was mir aber aufgefallen ist: Bei der ST Link Software *) ändert sich
die Reihenfolge der bytes wenn ich die Wortbreite der Anzeige
umschalte. So richtig verstanden habe ich den Effekt nicht.
Passt die Endianess von der ST-Link Anzeige nicht zu meinem
Chip/Adressschema oder sehe ich da einen anderen Effekt?

O.J.

*) Die ist bei mir schon etwas älter, Feb. 2015...

Thorsten Böttcher
Guest

Fri Feb 14, 2020 9:45 am   



Am 14.02.2020 um 08:49 schrieb Ole Jansen:

Quote:
Was mir aber aufgefallen ist: Bei der ST Link Software *) ändert sich
die Reihenfolge der bytes wenn ich die Wortbreite der Anzeige
umschalte. So richtig verstanden habe ich den Effekt nicht.


Bei mir auch, gerade ausprobiert.

Quote:
Passt die Endianess von der ST-Link Anzeige nicht zu meinem
Chip/Adressschema oder sehe ich da einen anderen Effekt?


Die Software zeigt den Wert der Speicherstelle an, und je nachdem welche
Datenbreite Du eingestellt hast, werden 1, 2 oder 4 Bytes dazu genommen.

Bei der Einstellung 8 bits sieht man IMHO die tatsächliche
Speicherbelegung, bei 16 oder 32 bits nicht mehr.

Volker Bartheld
Guest

Fri Feb 14, 2020 10:45 am   



Hallo!

On Fri, 14 Feb 2020 08:17:31 +0100, Ole Jansen wrote:
Quote:
Die "EEPROM Simulation" von ST verwendet zwei Speicherseiten und setzt am
Anfang der Seiten jeweils Flags welche Seite aktiv ist. Bei den C der
Connectivity Line sind die Seiten 2048 bytes gro [...] Angenommen also
ich verwende 4096 byte Flash speicher, schreibe 4 byte pro Update und
erlaube 10000 Lschzyklen, dann reichte das fr grob 1e7 Ereignisse
minus Verluste durch Overhead/Kopieren anderer Parameter. Erwartet
werden worst case 4e8 Ereignisse.


Verstanden. Die EEPROM-Simulation taugt also nicht fr Deinen
Anwendungsfall bzw. man mu sie erweitern, damit sie nicht nur auf 2*2048
Bytes funktioniert, sondern auf - sagen wir - 16*2048. Das ist dann immer
noch nicht ressourcenschonend und dem Problem angemessen, kann aber
funktionieren, wenn geringe BOM-Kosten und minimaler Softwareaufwand
oberste Prioritt haben. Brownout-Handling mu nmlich auch einigermaen
schlau (=zuverlssig) implementiert werden, denn viel Zeit fr
irgendwelche Datenrettung hat man da typischerweise nicht.

Quote:
In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzursten,
Wenn ich die Firmware rausrechne htte ich noch ca. 40k soda Flash
Speicher die ich sinnlos kaputtrsten "darf". Sagen die Auditoren...
Ich bin bei sowas aber aber sthet [...]


Und das ist auch gut so. Mir hngen die halbgaren, mit geringstmglichem
Aufwand einfach so hingerotzten Lsungen, die unter der Knute
irgendwelcher Projektmanager entstehen, nmlich zum Hals raus. Sowas mu
mindestens als grob fahrlssige Gedankenlosigkeit bezeichnet werden,
mglicherweise aber auch mit wissentlicher "Planned Obsolescence" bzw. dem
erhobenen Stinkefinger gegenber Menschen, die noch ansatzweise soetwas
wie Berufsehre im Leib haben.

Mich nervte es damals schon, als der Motorola-Microcontroller im
Concert/Chorus-Autoradio meines olympischen Alptraums vergelich wurde,
nur, weil irgendso ein Arsch bei Blaupunkt es eine gute Idee fand, jede
Eingabe sofort synchron aufs Flash zu schreiben, anstatt das erst im RAM
zu puffern und nur kurz vor dem Standby zu bertragen.

Nur damit wir uns richtig verstehen: Der Motorcola 68HC705B32 hat 4kB
EEPROM und 176 Bytes RAM und in diesem Radio ist fr ihn nichts weiter zu
tun als Managementaufgaben, weil es parallel dazu noch einen DSP gibt. Die
paar abzuspeichernden Parameter Lautstrke, Treble, Bass, Fader, Balance,
Kanal, Frequenzband, TP/RDS wird man schon in einer Handvoll Bytes
unterbringen knnen und selbst wer die Mglichkeiten des Soft-Off-Tasters
ignoriert, kann bei vernnftiger Nutzung der 4kB Flash schon auch bei nur
1000 mglichen Zyklen musealer Elektronik zuverlssig verhindern, da die
Dinger nach 10 Jahren sterben wie die Fliegen.

Aber nein, lieber zwingt man den User, ein 44-Pin PLCC auszulten,
irgendeinen funktionsgleichen Klon aus China zu orgen und dort die
reverseengineerte Software aufzuspielen.

Wer jetzt "alter Kse" ruft, mge sich einfach den Fall mit der Tesla MCU
[1] ansehen. Daraus:

"The information logged [on the Flash NAND] is pretty much useless on
production vehicles. Unless a developer has a specific reason for enabling
it, it does the customer no good. These logs are also rarely downloaded by
Tesla. [...] The main issue is that this excessive log file writing causes
eMMC flash wear. [...] Tesla selected a flash chip that is unable to
handle the constant read/write functions. These chips have since been
replaced with a more robust version. [...]".

Das ist ja eigentlich noch frivoler. Geschissen darauf, da zahlende User
sich mit einer potentiellen Reparaturrechnung von fast 2k konfrontiert
sehen. Und nur, weil irgendeine Coderdrohne #ifdef _DEBUG ... #endif um
seinen Loggercode vergessen hat.

Mannomann. Solche Leute sollte man in einen Knast stecken, wo sie *auf*
einem Sinclair ZX Spectrum mit 48kB, Gummitastatur und Rhrenglotze
Software *fr* einen ZX Spectrum mit 48k entwickeln drfen. Wir wollen mal
nicht so sein: Das DivIDE Interface [2] ist erlaubt, ebenso HiSoft Devpac
[3] und eine Papierausgabe von Rodnay Zaks "Programming the Z80" [3].

Nicht, da wir rger mit irgendwelchen Menschenrechtsaktivisten kriegen.

Ciao,
Volker

[1] https://insideevs.com/news/376037/tesla-mcu-emmc-memory-issue
[2] http://rwapsoftware.co.uk/spectrum/spectrum_storage.html
[3] http://www.worldofspectrum.org/infoseekid.cgi?id=0008091
[4] http://www.z80.info/zaks.html

Helmut Schellong
Guest

Fri Feb 14, 2020 1:45 pm   



On 02/13/2020 20:43, Volker Bartheld wrote:

Quote:
In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzursten,
sondern die Zhlerei im SRAM zu veranstalten und nur alle naslang genau
die notwendigen Daten von SRAM in den Flash zu bertragen. Natrlich mu
man sich das mit der Stromaufnahme und den Standbyzyklen genau berlegen
und auch Vorkehrungen fr den Brownout treffen, d. h. vielleicht einen
Goldcap verwenden und mittels Betriebsspannungsberwachung die Daten
wegschreiben, bevor dem Chip der Saft ausgeht.


Ich habe lange mit AT45DB041D (atmel) gearbeitet.
Eines ist extrem wichtig:
Nach jedem Schreiben in eine Page mu unbedingt
pauschal ein 'AUTO PAGE REWRITE' gemacht werden.

Kollegen von mir machten das nicht.
Und beim Kunden haben nach wenigen Wochen alle diese
Flash-Speicher versagt und alle Anlagen blieben stehen.


--
Mit freundlichen Gren
Helmut Schellong var_at_schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm

Ole Jansen
Guest

Fri Feb 14, 2020 1:45 pm   



Am 14.02.2020 um 10:30 schrieb Volker Bartheld:

Quote:
Verstanden. Die EEPROM-Simulation taugt also nicht fr Deinen
Anwendungsfall bzw. man mu sie erweitern, damit sie nicht nur auf 2*2048
Bytes funktioniert, sondern auf - sagen wir - 16*2048.


Genau. Durch kleien nderungen knnte man x Seiten verwenden.
Die Abnutzung verringerte sich entsprechend.

Quote:
Brownout-Handling mu nmlich auch einigermaen
schlau (=zuverlssig) implementiert werden, denn viel Zeit fr
irgendwelche Datenrettung hat man da typischerweise nicht.


Es gibt keine Software On/Off. Ein/Ausschalten geschieht
ber Betriebsspannungsunterbrechung. Ob die Zeit zwischen
der Unterbrechung der Spannungszufuhr und Brownout ausreicht
um das Flash zu updaten habe ich noch nicht erforscht.
Ausserdem gibt es noch folgendes Problem: Wenn der Watchdog
einen Reset auslst verliere ich Ereignisse.

Quote:
In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzursten,

Wenn ich die Firmware rausrechne htte ich noch ca. 40k soda Flash
Speicher die ich sinnlos kaputtrsten "darf". Sagen die Auditoren...
Ich bin bei sowas aber aber sthet [...]

Mich nervte es damals schon, als der Motorola-Microcontroller im
Concert/Chorus-Autoradio meines olympischen Alptraums vergelich wurde,
nur, weil irgendso ein Arsch bei Blaupunkt es eine gute Idee fand, jede
Eingabe sofort synchron aufs Flash zu schreiben, anstatt das erst im RAM
zu puffern und nur kurz vor dem Standby zu bertragen.


Ich glaube ich erinnere mich, darber hattest Du schon mal
was geschrieben ;-)

Quote:
Aber nein, lieber zwingt man den User, ein 44-Pin PLCC auszulten,
irgendeinen funktionsgleichen Klon aus China zu orgen und dort die
reverseengineerte Software aufzuspielen.


Verbuchen wir unter Training, ja?

Quote:
Wer jetzt "alter Kse" ruft, mge sich einfach den Fall mit der Tesla MCU
[1] ansehen. Daraus:

"The information logged [on the Flash NAND] is pretty much useless on
production vehicles. Unless a developer has a specific reason for enabling
it, it does the customer no good. These logs are also rarely downloaded by
Tesla. [...] The main issue is that this excessive log file writing causes
eMMC flash wear. [...] Tesla selected a flash chip that is unable to
handle the constant read/write functions. These chips have since been
replaced with a more robust version. [...]".


Dabei ist ihre Software neben der Marke das grte Asset von der Firma.
Mit ihrer Hardware drftem die kein Geld verdienen.

Quote:
Das ist ja eigentlich noch frivoler. Geschissen darauf, da zahlende User
sich mit einer potentiellen Reparaturrechnung von fast 2k konfrontiert
sehen. Und nur, weil irgendeine Coderdrohne #ifdef _DEBUG ... #endif um
seinen Loggercode vergessen hat.


Solange sie nicht bei Programmieren vergessen die richtigen Fuse Bits zu
setzen...

> Nicht, da wir rger mit irgendwelchen Menschenrechtsaktivisten kriegen.

Die sind nicht so schlimm wie beleidigte TESLA-Fanboys. Glaube ich...

O.J.

Goto page 1, 2, 3  Next

elektroda.net NewsGroups Forum Index - Electronics DE - STM32FXX Flash Speicher weniger abnutzen

NEUES THEMA

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com
WTWHMEDIA