STM32FXX Flash Speicher weniger abnutzen

[Hanno Foest]

Am 14.02.20 um 15:00 schrieb Ole Jansen:

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

Nö. In Bereichen, in denen ich mich nicht auskenne, muß ich mich leider
auf die Presse verlassen, und die schreibt da nichts von "nicht
ausreichend". Und vielleicht macht ja ein junges Unternehmen wie Tesla
ein paar Sachen anders, oder gar besser. Vertrieb und Marketing würden
mir einfallen. Vielleicht auch Wasserkopf, wegen des Zeitfaktors.

Hanno

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

 

[Volker Bartheld]

On Fri, 14 Feb 2020 14:23:27 +0100, Hanno Foest wrote:

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.

Peinlich ist eine ganz andere Sache, nämlich der Umgang damit: '[...]
"Tesla has known about this issue for years now and has done nothing to
mitigate it. I've personally reported it on multiple occasions, and I know
others have as well. I've noted this to Tesla on several occasions,
starting in late 2015, and several times since." [...]', aka. jahrelang
die Beine stillhalten, dann - auf wachsenden Druck irgendwann
zähneknirschend innerhalb (und nur dann!) der Gewährleistungsfrist das
ganze Board austauschen, spezialisierte Firmen aussperren, die nur das BGA
tauschen kĂśnnten.

Und was wurde daraus gelernt? Einfach: "Instead of mitigating the issue, it
writes even more data to the logs today than ever before. Combined with
the max-size firmware images, general caching – map tiles, Autopilot info,
music, etc. – this makes every MCUv1 have a high probability of failure."
so Jason Hughes, einer derjenigen die das Problem offiziell lĂśsen kĂśnnten,
aber nicht dĂźrfen.

Also genau das, was man von solchen Unternehmen erwartet, in guter
Gesellschaft mit z. B. Apple. Ist den Fanboys aber egal, die haben ihr
lustiges Spielzeug und fertig.

Volker

 

[Hanno Foest]

Am 14.02.20 um 16:35 schrieb Volker Bartheld:

Und was wurde daraus gelernt? Einfach: "Instead of mitigating the issue, it
writes even more data to the logs today than ever before. Combined with
the max-size firmware images, general caching – map tiles, Autopilot info,
music, etc. – this makes every MCUv1 have a high probability of failure."
so Jason Hughes, einer derjenigen die das Problem offiziell lĂśsen kĂśnnten,
aber nicht dĂźrfen.

Finde ich insofern seltsam, als die Karren doch eh ständig online sind.
Was muß man da so viel loggen?

Also genau das, was man von solchen Unternehmen erwartet, in guter
Gesellschaft mit z. B. Apple. Ist den Fanboys aber egal, die haben ihr
lustiges Spielzeug und fertig.

Ich bin generell altmodisch und mag mir keine Geräte zulegen, ßber die
jemand anderes die Kontrolle hat. Vgl. auch

https://www.golem.de/news/software-tesla-deaktiviert-autopilot-funktionen-bei-gebrauchtwagen-2002-146528.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.

 

[Volker Bartheld]

On Fri, 14 Feb 2020 17:16:29 +0100, Hanno Foest wrote:

Ich bin generell altmodisch und mag mir keine Geräte zulegen, über die
jemand anderes die Kontrolle hat. Vgl. auch
https://www.golem.de/news/software-tesla-deaktiviert-autopilot-funktionen-bei-gebrauchtwagen-2002-146528.html

Ach was. Nichts gegen einzuwenden, wenn Du z. B. eine ¤¤¤ SD-Karte mit
WiFi-Funktionalität kaufst und dann gearscht bist, weil der Hersteller den
zwingend erforderlichen Onlinesupport einstellt *). Kannst ja das
Nachfolgemodell kaufen, von irgendwas müssen die schließlich auch leben.

Volker

*) https://www.diyphotography.net/eyefi-drop-support-cards-will-magically-stop-working-september-16-2016/
Ja, nee, es gab einen Shitstorm und EyeFi ist schließlich eingeknickt.
Vermutlich hatten sie ihre Gewährleistungsbedingungen nicht richtig
formuliert.

 

[Helmut Schellong]

On 02/14/2020 14:27, Thorsten Böttcher wrote:

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.

Die Interpretation meines Satzes paßt nicht.
Das heißt, ich hätte es mehrfach ausführlicher schreiben sollen,
damit es eindeutig verstanden wird.

Ich meine damit, daß eine Funktion eine Page aus dem Flash
in das RAM liest und ändert.
Nach dieser Page/Schleife wird das RAM in die Page kopiert
und pauschal 'AUTO PAGE REWRITE' durchgeführt.

Ich habe grundsätzlich dies Paar:
FL_write(FL_CONFIG+pga, buf.b, _264);
FL_rewrite(FL_CONFIG+pga, 1);
programmiert.

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.

Meine Kollegen hatten gar kein Rewrite programmiert.
Prompt kam es zur beschriebenen Katastrophe.

Nachdem sie es machten wie ich, war dies Problem weg.

Früher hab ich mitgezählt, und wenn die Zahl erreicht war, hab ich den
Speicher beim Einschalten komplett aufgefrischt.

Das finde ich in meinem Kontext zu unsicher und zu aufwendig.

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.

Bei uns rächte sich die Unterlassung schnell.


Code-Beispiel:

void CopyDefaultsToCfg(void)
{
CFG_t *sp;
UNS pga, rpga, rest, adr, len;
UNS const pgae= MU.anzcfgpg*_264;
union { BYTE b[_264+OBJMAX*2]; UNS2 w[(_264+OBJMAX*2)/2]; } buf, rbuf;
UNS2 n, z;

memsetw(buf.w, 0xFFFFu, sizeof(buf.w)/2);
for (pga=0; pga<pgae; pga=rpga?rpgaga+_264) {
for (rpga=rest=0,sp=CFGdata; sp->grp; ++sp) {
adr= sp->adr;
if (adr>=pga && adr<pga+_264) {
adr-=pga; len=sp->len; n=sp->nelem; z=0;
do {
if (sp->dfstr)
strncpyNF_F((z?rbuf.b:buf.b)+adr, sp->dfstr , len);
else memcpyNF_F((z?rbuf.b:buf.b)+adr, sp->dfmima, len);
adr+=len;
if (!z) { //COPYTO(buf.b);
if (adr>_264) { z=1;
rpga=pga+_264; adr-=_264;
memsetw(rbuf.w, 0xFFFFu, sizeof(rbuf.w)/2);
memcpy_F(rbuf.b, buf.b+_264, adr);
}
}
else { //COPYTO(rbuf.b);
if (adr>=_264) {
WD_RESET;
FL_write(FL_CONFIG+rpga, rbuf.b, _264);
FL_rewrite(FL_CONFIG+rpga, 1);
rpga+=_264;
memsetw(rbuf.w, 0xFFFFu, _264/2);
if ((adr-=_264)>0) memcpy_F(rbuf.b, rbuf.b+_264, adr);
memsetw(rbuf.b+_264, 0xFFFFu, (OBJMAX*2)/2);
}
}
}
while (--n);
if (z) rest=adr;
}
}
WD_RESET;
FL_write(FL_CONFIG+pga, buf.b, _264);
FL_rewrite(FL_CONFIG+pga, 1);
memsetw(buf.w, 0xFFFFu, sizeof(buf.w)/2);
if (rest) memcpy_F(buf.b, rbuf.b, rest);
}
return;
}


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

 

[Falk Willberg]

On 14.02.20 13:45, Ole Jansen wrote:
> Am 14.02.2020 um 10:30 schrieb Volker Bartheld:

....

Ausserdem gibt es noch folgendes Problem: Wenn der Watchdog
einen Reset auslĂśst verliere ich Ereignisse.

Wenn der WD auslĂśst, ist die FW sowieso kaputt^Wbuggy.

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

Sowas lese ich gerne. Außerdem ist das kaputtrösten von nKb Flash etwa
so schwierig, wie drei von zehn Spiegeleier in der gleichen Pfanne
anbrennen zu lassen.

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.

Die Firmware in meinem Auto wird auch vergesslich. Regelmäßig wenn ich
mich Ăźber OBD-II verbunden habe, geht irgendwann der KĂźhlerlĂźfter auf
kleinster Stufe an, was vollständig sinnlos ist.
Da hilft Ziehen und wieder Stecken der 200A-Sicherung der
Traktionsbatterie. Beim letzten Mal hat das Steuergerät dabei die
Parameter fĂźrs Fahrpoti vergessen: Ich konnte zwar auf ~90% des Weges
unglaublich gefĂźhlvoll verzĂśgern aber auf den verbleibenden 10% nur in
groben Stufen und auch nur mit 50% des Maximums beschleunigen. Naja,
irgendwas ist ja immer ;-

Dabei ist ihre Software neben der Marke das größte Asset von der Firma.
Mit ihrer Hardware dĂźrftem die kein Geld verdienen.

Das trifft auf Microsoft ebenso zu und ... ähem.... tja....

....

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

Mein TESLA-Kollege ist als APPLE-Fanboy schlimmer ;-)

Falk

 

[Ole Jansen]

Am 14.02.2020 um 16:28 schrieb Hanno Foest:

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

Nö. In Bereichen, in denen ich mich nicht auskenne, muß ich mich leider
auf die Presse verlassen, und die schreibt da nichts von "nicht
ausreichend".

Capital und Focus schreiben was dazu, die Artikel sind aber hinter
den Bezahlschranken nicht mehr auffindbar.
Ein Golf z.B. dürfte in der Größenordnung 4500¤ Materialkosten und
5000¤ Fabrikkosten liegen. Selbige Kosten für einen Tesla Model 3
liegen im Bereich von Luxusautomobilen. Die üblichen Endverkaufspreis
kennst Du.

Und vielleicht macht ja ein junges Unternehmen wie Tesla
ein paar Sachen anders, oder gar besser.

Auf alle Fälle anders als alle anderen etablierten Hersteller.

Vertrieb und Marketing würden
mir einfallen. Vielleicht auch Wasserkopf, wegen des Zeitfaktors.

Das finanziert sich aktuell nicht aus den Verkaufserlösen
sondern anders.

O.J.

 

[Hanno Foest]

Am 17.02.20 um 10:28 schrieb Ole Jansen:

Ein Golf z.B. dürfte in der Größenordnung 4500¤ Materialkosten und
5000¤ Fabrikkosten liegen. Selbige Kosten für einen Tesla Model 3
liegen im Bereich von Luxusautomobilen. Die üblichen Endverkaufspreis
kennst Du.

Kann ich nicht nachprüfen, mag sein. Ich gebe aber zu bedenken, daß VW
so gut zahlte, daß zumindest früher (keine Ahnung, wie sich das
entwickelt hat) es so ne Art Schwarzmarkt für VW Jobs gab. Ich kann mir
gut vorstellen, daß das woanders deutlich billiger geht.

Vertrieb und Marketing würden mir einfallen. Vielleicht auch
Wasserkopf, wegen des Zeitfaktors.

Das finanziert sich aktuell nicht aus den Verkaufserlösen
sondern anders.

Klar. Amazon hat auch ne Weile gebraucht, bis die profitabel waren.
Schaun wir mal.

Hanno

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

 

Am Montag, 17. Februar 2020 11:29:05 UTC+1 debilierte Hanno Foest:

--
Nie irgendwas […]

 

[Ole Jansen]

Am 12.02.2020 um 14:53 schrieb 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.

Ingrid stellt Folgendes fest: Der Chip hat CRC fĂźr Flash hart
verdrahtet und erlaubt vermutlich nur seitenweises LĂśschen auf 0xFFFF
und 16bit weises Schreiben und fragt daher was in diesem Fall am
sinnvollsten wäre um de FLASH mÜglichst wenig abzunutzen bzw. einen
robusten Zähler zu erhalten. Folgende Ideen:

Annahme 1: Beim Erase nutzen sich gewechselte bits mehr ab als
ungewechselte. Es ist daher am gĂźnstigsten beim Schreiben eines 16 bit
Wortes immer nur ein bit zu wechseln und bei jedem Durchlauf
auf ein anderes bit umzuschalten.

Annahme 2: Annahme1 ist falsch, aber bei einem "verbrannten"
Flash kippen oft nicht ganze Worte sondern einzelne bits.
Es ist am gĂźnstigsten beim Schreiben immer alle bits zu schreiben,
d.h. das ganze Wort von 0xFFFF auf 0x0000 setzen und beim
Lesen z.B. allss !=0xFFFF als 0x0000 zu interpretieren oder
ähnlich.

Annahme 3: Alles egal. Nach Soundsovielen Erase Zyklen ist
es sowieso kaputt und kaputte Zellen sind komplett unbeschreibbar.
Es wäre am sinnvollsten Schreibfehler zu erkennen und ggf. automatisch
auf Reserveseiten umzuschalten.

Irgendwelche Ratschläge?

Viele Grüße,

O.J.

 

[Thorsten BĂśttcher]

Am 17.02.2020 um 18:10 schrieb Ole Jansen:

Am 12.02.2020 um 14:53 schrieb 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.

Ingrid stellt Folgendes fest: Der Chip hat CRC fĂźr Flash hart
verdrahtet und erlaubt vermutlich nur seitenweises LĂśschen auf 0xFFFF

Dass man das Flash nur Seitenweise lĂśschen kann ist normal, und war IMHO
schon bei den 8 Bit AVR so.
Mit CRC hat das nichts zu tun.

Snip

> Irgendwelche Ratschläge?

Bis wieviel willst Du denn zählen? Und wie schnell musst Du zählen?

Es gab so viele gute LĂśsungsmĂśglichkeiten hier.
Goldcap, Spannungserkennung und nur ab und zu schreiben, oder FRAM dran
und quasi unbegrenzte Schreibzyklen.
Oder halt, wenn Du unbedingt nur den Prozessor benutzen willst, eine
Flashseite nach der nächsten verheizen.

 

[Ole Jansen]

Am 18.02.2020 um 07:19 schrieb Thorsten BĂśttcher:

Dass man das Flash nur Seitenweise lĂśschen kann ist normal, und war IMHO
schon bei den 8 Bit AVR so.
Mit CRC hat das nichts zu tun.

Das mit dem LĂśschen ist klar. Es ging um das Schreiben. Bei meinem
ST kĂśnnen keine FLASH Adressen Ăźberschrieben werden die nicht
0xFFFF sind. Das war mir am Anfang nicht ganz klar.

Irgendwelche Ratschläge?

Bis wieviel willst Du denn zählen? Und wie schnell musst Du zählen?

Bis etwa 4x10^8 mit max 70Hz.

Es gab so viele gute LĂśsungsmĂśglichkeiten hier.
Goldcap, Spannungserkennung und nur ab und zu schreiben, oder FRAM dran
und quasi unbegrenzte Schreibzyklen.

Ja, weiß ich.

Oder halt, wenn Du unbedingt nur den Prozessor benutzen willst, eine
Flashseite nach der nächsten verheizen.

Präferiert wäre eine SoftwarelÜsung die in ein ein vorhandenes Design
passt. Plan B ist der Ersatz durch einen anderen pinkompatiblen Chip.
Designänderung wäre Plan C. Bislang habe ich es geschaff den Code so
weit zu entschlacken dass im ÂľC etwa 40k Flash zur freien VerfĂźgung
wären.

O.J.

 

[Thomas Prufer]

On Tue, 18 Feb 2020 07:53:09 +0100, Ole Jansen
<remove.this.kaspernasebaer@gmx.de> wrote:

Präferiert wäre eine Softwarelösung die in ein ein vorhandenes Design
passt. Plan B ist der Ersatz durch einen anderen pinkompatiblen Chip.
Designänderung wäre Plan C. Bislang habe ich es geschaff den Code so
weit zu entschlacken dass im ľC etwa 40k Flash zur freien Verfügung
wären.

Schmeiß den Softwaremist weg und bau sowas ein:

<https://de.wikipedia.org/wiki/Betriebsstundenz%C3%A4hler#Quecksilber-Coulometer>

(Nein, das mein ich nicht ernst, aber ich find die Dinger supercool. Nix dran,
nix drin, reset durch Umdrehen, gusseisern bis EMP-fest, ... Über die Auflösung
sag ich mal nix.)


Thomas Prufer

 

[Ole Jansen]

Am 18.02.2020 um 09:11 schrieb Thomas Prufer:

Schmeiß den Softwaremist weg und bau sowas ein:

https://de.wikipedia.org/wiki/Betriebsstundenz%C3%A4hler#Quecksilber-Coulometer

Hihi, sowas hab ich noch neulich noch in einem alter Interferometer
gefunden. Betriebsstundenzähler fßr den HeNe-Laser. Gibts die auch
mit ROHS? <duck weg>

O.J.

 

[Thomas Prufer]

On Tue, 18 Feb 2020 14:22:28 +0100, Ole Jansen
<remove.this.kaspernasebaer@gmx.de> wrote:

Hihi, sowas hab ich noch neulich noch in einem alter Interferometer
gefunden. Betriebsstundenzähler für den HeNe-Laser. Gibts die auch
mit ROHS? <duck weg

O.J.

"Freilich ist das bleifrei."

<auch duckundweg>

Thomas Prufer