STM32FXX Flash Speicher weniger abnutzen

[Ole Jansen]

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]

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:

- 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]

Ole Jansen <remove.this.kaspernasebaer@gmx.de> wrote:

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

- 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 .

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@elektron.ikp.physik.tu-darmstadt.de

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

 

[Marte Schwarz]

Hi Ole,

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.

mitgelieferte Bibliothek verwendet fĂźrs Schreiben einer Zelle
jeweils ein word mit 2 byte.

Eher 4 bei einem 32 Bit ÂľC

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

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

- 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

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]

Moin,

Am 12.02.2020 um 16:27 schrieb Andreas Fecht:

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.

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.

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.

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.

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]

Am 13.02.2020 um 08:54 schrieb Ole Jansen:

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]

Am 13.02.2020 um 08:54 schrieb Ole Jansen:

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]

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]

Servus!

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?

In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzurösten,
sondern die Zählerei im SRAM zu veranstalten und nur alle naslang genau
die notwendigen Daten von SRAM in den Flash zu übertragen. Natürlich muß
man sich das mit der Stromaufnahme und den Standbyzyklen genau überlegen
und auch Vorkehrungen für den Brownout treffen, d. h. vielleicht einen
Goldcap verwenden und mittels Betriebsspannungsüberwachung die Daten
wegschreiben, bevor dem Chip der Saft ausgeht.

Irgendwelche Magie mit Bitjongliererei macht die Sache nur unnötig
kompliziert und fehleranfällig. Wie stellst Du Dir das vor? Die
Holzhammermethode, wo man den Speicher nicht in Words aufteilt, sondern
einfach einen Bandwurm von Bits mit Nullen füllt, 100 Nullen sind dann 100
Ereignisse, usw.?

Und: 256k Flash für einen Ereigniszähler? Echt jetzt? 2^2097152 Ereignisse?
Wieviele Atome in wievielen Universen willst Du denn zählen? Falls Du also
nicht den vollen Speicher benötigst, hättest Du immer noch 20
Speicherseiten, über die Du permutieren könntest (wenn sie sich nur als
Ganzes löschen 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 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.

Ciao,
Volker

 

[Ole Jansen]

Hallo Volker,

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 ;-)

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.

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.

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

Das ist durchaus eine Alternative.

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!

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]

Am 13.02.2020 um 11:43 schrieb Andreas Fecht:

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.

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.

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

OK.

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]

Am 14.02.2020 um 08:49 schrieb Ole Jansen:

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.

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]

Hallo!

On Fri, 14 Feb 2020 08:17:31 +0100, Ole Jansen wrote:

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 Löschzyklen, dann reichte das für grob 1e7 Ereignisse
minus Verluste durch Overhead/Kopieren anderer Parameter. Erwartet
werden worst case 4e8 Ereignisse.

Verstanden. Die EEPROM-Simulation taugt also nicht für 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 Priorität haben. Brownout-Handling muß nämlich auch einigermaßen
schlau (=zuverlässig) implementiert werden, denn viel Zeit für
irgendwelche Datenrettung hat man da typischerweise nicht.

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 das ist auch gut so. Mir hängen die halbgaren, mit geringstmöglichem
Aufwand einfach so hingerotzten Lösungen, die unter der Knute
irgendwelcher Projektmanager entstehen, nämlich zum Hals raus. Sowas muß
mindestens als grob fahrlässige Gedankenlosigkeit bezeichnet werden,
möglicherweise aber auch mit wissentlicher "Planned Obsolescence" bzw. dem
erhobenen Stinkefinger gegenüber 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 vergeßlich 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 für ihn nichts weiter zu
tun als Managementaufgaben, weil es parallel dazu noch einen DSP gibt. Die
paar abzuspeichernden Parameter Lautstärke, Treble, Bass, Fader, Balance,
Kanal, Frequenzband, TP/RDS wird man schon in einer Handvoll Bytes
unterbringen können und selbst wer die Möglichkeiten des Soft-Off-Tasters
ignoriert, kann bei vernünftiger Nutzung der 4kB Flash schon auch bei nur
1000 möglichen Zyklen musealer Elektronik zuverlässig verhindern, daß die
Dinger nach 10 Jahren sterben wie die Fliegen.

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

Wer jetzt "alter Käse" ruft, möge 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 Röhrenglotze
Software *für* einen ZX Spectrum mit 48k entwickeln dürfen. 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]

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

In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzurösten,
sondern die Zählerei im SRAM zu veranstalten und nur alle naslang genau
die notwendigen Daten von SRAM in den Flash zu übertragen. Natürlich muß
man sich das mit der Stromaufnahme und den Standbyzyklen genau überlegen
und auch Vorkehrungen für den Brownout treffen, d. h. vielleicht einen
Goldcap verwenden und mittels Betriebsspannungsüberwachung 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 Grüßen
Helmut Schellong var@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]

Am 14.02.2020 um 10:30 schrieb Volker Bartheld:

Verstanden. Die EEPROM-Simulation taugt also nicht für 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 könnte man x Seiten verwenden.
Die Abnutzung verringerte sich entsprechend.

Brownout-Handling muß nämlich auch einigermaßen
schlau (=zuverlässig) implementiert werden, denn viel Zeit für
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 auslöst verliere ich 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 [...]

Mich nervte es damals schon, als der Motorola-Microcontroller im
Concert/Chorus-Autoradio meines olympischen Alptraums vergeßlich 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, darüber hattest Du schon mal
was geschrieben ;-)

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

Verbuchen wir unter Training, ja?

Wer jetzt "alter Käse" ruft, möge 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 größte Asset von der Firma.
Mit ihrer Hardware dürftem die kein Geld verdienen.

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.

 

[Hans-Peter Diettrich]

Am 12.02.2020 um 14:53 schrieb Ole Jansen:

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

Wie wäre es mit einer Uhr (RTC mit Batterie), und Speicherung des
Zählers im CMOS RAM? Dann wird das Speichern nur durch die Lebensdauer
der Batterie begrenzt.

DoDi

 

[Hanno Foest]

Am 14.02.20 um 13:45 schrieb Ole Jansen:

[Tesla NAND Problem]
> Dabei ist ihre Software neben der Marke das größte Asset von der Firma.

Na ja, shit happens. Peinlich ist es jedenfalls.

> Mit ihrer Hardware dürftem die kein Geld verdienen.

https://www.wiwo.de/technologie/mobilitaet/elektroauto-zerlegt-tesla-model-3-kann-gewinn-abwerfen/22625806.html

Hanno

--
Nie irgendwas von Ulf Kutzner glauben, insbesondere Zitate immer im
Original und Kontext nachlesen. Er versucht, durch Zitatefälschung
Strohmann-Argumente zu konstruieren.

 

[Thorsten BĂśttcher]

Am 14.02.2020 um 13:06 schrieb Helmut Schellong:

Ich habe lange mit AT45DB041D (atmel) gearbeitet.

Ich auch, allerdings mit der großen Version, AT45DB641.
Der Baustein, bzw. der Nachfolger wird immer noch verbaut.

Eines ist extrem wichtig:
Nach jedem Schreiben in eine Page muß unbedingt
pauschal ein 'AUTO PAGE REWRITE' gemacht werden.

Das steht aber so nicht im Datenblatt, und meine Erfahrung sagt das gleiche.
Wenn Daten in zufälliger Reihenfolge, in einem Sektor verteilt
geschrieben werden, soll ca. alle 10000 page erase/programm Operationen
ein Auto Page Rewrite ausgeführt werden. Beim aktuellen Baustein sind es
sogar 50000.

Kollegen von mir machten das nicht.

Mache ich auch nicht.

Und beim Kunden haben nach wenigen Wochen alle diese
Flash-Speicher versagt und alle Anlagen blieben stehen.

Früher hab ich mitgezählt, und wenn die Zahl erreicht war, hab ich den
Speicher beim Einschalten komplett aufgefrischt.
Mittlerweile lass ich das weg.
Datenverlust ist mir bis jetzt keiner gemeldet worden.
Und es kommen teilweise Geräte zur Überprüfung/Reparatur*, die älter als
10 Jahre sind.

*Aus anderen Gründen, meistens mechanische Schäden.

 

[Ole Jansen]

Am 14.02.2020 um 09:33 schrieb Thorsten BĂśttcher:

Bei der Einstellung 8 bits sieht man IMHO die tatsächliche
Speicherbelegung

Also die "physische" ?

> bei 16 oder 32 bits nicht mehr.

Da zeigt er dann wohl "Übersetzung" nach Little Endian an.
Was dann dem entspricht was die Routinen in meinem Code
lesen und schreiben.

Ähh, ich glaube jetzt habe ich es verstanden.

O.J.

 

[Ole Jansen]

Am 14.02.2020 um 14:23 schrieb Hanno Foest:
>> Mit ihrer Hardware dürftem die kein Geld verdienen.

Aktuell.

https://www.wiwo.de/technologie/mobilitaet/elektroauto-zerlegt-tesla-model-3-kann-gewinn-abwerfen/22625806.html

OK. Es ist also bei Model3 theoretisch denkbar dass der
Bruttoverkaufserlös BOM und Montage abdeckt. Vielleicht hilft ja die
neue Fabrik im "Billiglohnland" D

BTW: Du kennst die üblicherweise als "ausreichend" angesehenen Margen
im Fahrzeugbau zur Deckung von F&E, Compliance, Wasserkopf, Dividende,
Vertrieb und Marketing usw. ?

O.J.