Moin,
Der Chip hat in seinem Flash Speicherseiten mit 2048 bytes die als
jeweils ein word mit 2 byte.
EEPROM-Simulation die hier beschrieben ist und etwa 4 byte
Parameters neu beschreibt:
die Abnutzung des Flashspeichers zu hoch wird (Etwa Faktor 40). Daher die Frage:
( 0XFF, 0XFE, 0XFC ... 0X00)?
Kennt jemand den Chip oder die Funktionsweise des internen Flash etwas genauer oder hat einen anderen Tip?
O.J.
Am 12.02.2020 um 14:53 schrieb Ole Jansen:
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!oder 0 sein.
Ole Jansen wrote: > Moin,
Bei STM32F1 werden immer Worte geschrieben
0xffff erhaelst Du mit Page Erase. Danach kannst du Bit nur noch nach Null schreiben. Das aber auch in vielen verschiedenen Schreibvorgaenngen .Was spricht gegen die Art und Weise wie ST das implementier?
Hi Ole,
klingt logisch
Nein
schreiben, wenn die Spannungsversorgung zusammenbricht.
Marte
Moin,
Am 12.02.2020 um 16:27 schrieb Andreas Fecht:
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
Weiss ich ehrlich gesagt nicht.
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.
Mein Muster hier kann 16bit oder 32bit usw. Wenn sich Footprint
Nullen in die Speicherzellen zu schreiben und einen Chip mit
Hier sind sie 0xFF, also 1. Wobei das auch sein kann dass der Speicher
gut portierbar schreiben.
O.J.
Am 13.02.2020 um 08:54 schrieb Ole Jansen:
jeder weiteren Page nochmal um 163Mio.
Wenn's nicht bitweise geht, verringert sich der Wert bei 32-Bit-Worten
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
adressieren, bei krummen Adressen, die nicht auf die Busbreite des Flashinterfaces matchen, hagelt es Fehler.
Am 13.02.2020 um 08:54 schrieb Ole Jansen:
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.
erstmal grob den Typ zu wissen.
Bytes/Words setzt. Testpin schalten damit man sieht wie lange
Der andere Aspekt ist unkontrollierter power down. D.h. der
laufendem Betrieb die Batterien herausnehmen oder den Netzstecker ziehen.
hoffentlich undemolierte Speicherseite als Startwert verwendet.
schneller als EEPROM/Flash.
MfG JRD
auszuweichen, die (nur) 64kB Flash und 64kB SRAM hat?
wegschreiben, bevor dem Chip der Saft ausgeht.
Holzhammermethode, wo man den Speicher nicht in Words aufteilt, sondern
Ereignisse, usw.?
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
x*200'000 Zyklen halten.
Ciao, Volker
Hallo Volker,
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.
Die Routine schreibt Parameter weg indem eine definierte "virtual adress" (16bit) gefolgt von dem Wert (16bit) an die
Wenn die Seite voll ist geht er die Liste mit den ihm
Seite und kopiert alle gespeicherten Parameter dorthin und setzt die Seite aktiv. Damit wird einerseits die
Inkonsistenzen erkennen und ggf. alles auf den letzten
Angenommen also ich verwende 4096 byte Flash speicher,
durch Overhead/Kopieren anderer Parameter. Erwartet werden worst case 4e8 Ereignisse.
den Quellcode gegenliest der sich auskennt ;-)
Zur Zeit gibt es kein batteriegepuffertes RAM oder externes EEPROM.
Das ist durchaus eine Alternative.
Ich verwende zwei Seiten. Inkremente werden in Word0 gespeichert
auf word0 der anderen Seite analog zur EEPROM Simulation wie oben
mit zwei Speicherseiten ausreichen.
Denk an Moores Gesetz. Der Markt schreit geradezu nach
Alle!
wenn man die 10000 nicht so eng sieht.
echten Contoller. Ich vermute stark dass Andreas Recht hat und dass mein
O.J.
Am 13.02.2020 um 11:43 schrieb Andreas Fecht:
Die zeigt bei mit folgendes Verhalten:
- Dabei ist es egal ob ich in die Zelle den aktuellen
Ausnahme hiervon: 0xFFFF in eine Zelle schreiben
ProgramHalfWord kann bei mir 16bit weise. Weniger geht anscheinend nicht.
OK.
Hab ich noch nicht probiert.
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.
Am 14.02.2020 um 08:49 schrieb Ole Jansen:
Bei mir auch, gerade ausprobiert.
Die Software zeigt den Wert der Speicherstelle an, und je nachdem welche Datenbreite Du eingestellt hast, werden 1, 2 oder 4 Bytes dazu genommen.
Speicherbelegung, bei 16 oder 32 bits nicht mehr.
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
irgendwelche Datenrettung hat man da typischerweise nicht.
wie Berufsehre im Leib haben.
Mich nervte es damals schon, als der Motorola-Microcontroller im
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
Nur damit wir uns richtig verstehen: Der Motorcola 68HC705B32 hat 4kB
tun als Managementaufgaben, weil es parallel dazu noch einen DSP gibt. Die
Kanal, Frequenzband, TP/RDS wird man schon in einer Handvoll Bytes
Dinger nach 10 Jahren sterben wie die Fliegen.
irgendeinen funktionsgleichen Klon aus China zu orgen und dort die reverseengineerte Software aufzuspielen.
[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. [...]".
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*
nicht so sein: Das DivIDE Interface [2] ist erlaubt, ebenso HiSoft Devpac [3] und eine Papierausgabe von Rodnay Zaks "Programming the Z80" [3].
Ciao, Volker
[1]
Ich habe lange mit AT45DB041D (atmel) gearbeitet. Eines ist extrem wichtig:
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.
Am 14.02.2020 um 10:30 schrieb Volker Bartheld:
Die Abnutzung verringerte sich entsprechend.
Es gibt keine Software On/Off. Ein/Ausschalten geschieht
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
was geschrieben ;-)
Verbuchen wir unter Training, ja?
Solange sie nicht bei Programmieren vergessen die richtigen Fuse Bits zu setzen...
Die sind nicht so schlimm wie beleidigte TESLA-Fanboys. Glaube ich...
O.J.
Am 12.02.2020 um 14:53 schrieb Ole Jansen:
er der Batterie begrenzt.
DoDi
Also die "physische" ?
Was dann dem entspricht was die Routinen in meinem Code lesen und schreiben.
O.J.
Am 14.02.20 um 13:45 schrieb Ole Jansen:
[Tesla NAND Problem]Na ja, s*it happens. Peinlich ist es jedenfalls.
Hanno
Am 14.02.2020 um 13:06 schrieb Helmut Schellong:
Der Baustein, bzw. der Nachfolger wird immer noch verbaut.
Das steht aber so nicht im Datenblatt, und meine Erfahrung sagt das gleiche.
geschrieben werden, soll ca. alle 10000 page erase/programm Operationen
sogar 50000.
Mache ich auch nicht.
Speicher beim Einschalten komplett aufgefrischt. Mittlerweile lass ich das weg. Datenverlust ist mir bis jetzt keiner gemeldet worden.
10 Jahre sind.Am 14.02.2020 um 14:23 schrieb Hanno Foest:
Aktuell.
OK. Es ist also bei Model3 theoretisch denkbar dass der
neue Fabrik im "Billiglohnland" D :-P
im Fahrzeugbau zur Deckung von F&E, Compliance, Wasserkopf, Dividende, Vertrieb und Marketing usw. ?
O.J.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required