expertenaustausch > sci.* > sci.electronics

Hans-Peter Diettrich (14.02.2020, 14:53)
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
Ole Jansen (14.02.2020, 15:18)
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.
Hanno Foest (14.02.2020, 15:23)
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.




Hanno
Thorsten Böttcher (14.02.2020, 15:27)
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 (14.02.2020, 16:00)
Am 14.02.2020 um 14:23 schrieb Hanno Foest:
>> Mit ihrer Hardware dürftem die kein Geld verdienen.


Aktuell.

>


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

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.
Hanno Foest (14.02.2020, 17:28)
Am 14.02.20 um 15:00 schrieb Ole Jansen:

> 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 :-P
> 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
Volker Bartheld (14.02.2020, 17:35)
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 (14.02.2020, 18:16)
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



Hanno
Volker Bartheld (14.02.2020, 18:37)
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
>


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

*)
Ja, nee, es gab einen Shitstorm und EyeFi ist schließlich eingeknickt.
Vermutlich hatten sie ihre Gewährleistungsbedingungen nicht richtig
formuliert.
Helmut Schellong (14.02.2020, 18:46)
On 02/14/2020 14:27, Thorsten Böttcher wrote:
> Am 14.02.2020 um 13:06 schrieb Helmut Schellong:
> Ich auch, allerdings mit der großen Version, AT45DB641.
> Der Baustein, bzw. der Nachfolger wird immer noch verbaut.
> 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?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;
}
Falk Willberg (16.02.2020, 22:40)
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 (17.02.2020, 11:28)
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 (17.02.2020, 12:29)
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
Ulf.Kutzner (17.02.2020, 13:42)
Am Montag, 17. Februar 2020 11:29:05 UTC+1 debilierte Hanno Foest:
Ole Jansen (17.02.2020, 19:10)
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.

Ähnliche Themen