STM32FXX Flash Speicher weniger abnutzen

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

Am 14.02.20 um 16:35 schrieb Volker Bartheld:

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

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

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

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.

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

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

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

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?rpga:pga+_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; }

...

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

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.

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

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

...

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

Falk

Am 14.02.2020 um 16:28 schrieb Hanno Foest:

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

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

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

O.J.

Am 17.02.20 um 10:28 schrieb Ole Jansen:

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.

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

Hanno

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

Am 12.02.2020 um 14:53 schrieb Ole Jansen:

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.

Am 17.02.2020 um 18:10 schrieb Ole Jansen:

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

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.

Am 18.02.2020 um 07:19 schrieb Thorsten Böttcher:

Das mit dem Löschen ist klar. Es ging um das Schreiben. Bei meinem ST können keine FLASH Adressen überschrieben werden die nicht

Bis etwa 4x10^8 mit max 70Hz.

Ja, weiß ich.

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.

Schmeiß den Softwaremist weg und bau sowas ein:

(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

Am 18.02.2020 um 09:11 schrieb Thomas Prufer:

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

Thomas Prufer