MCU Problem / Emmc fail - Wer hier hat das Problem?

Da bin ich mir ziemlich sicher. Aber die MCU2 basiert auch auf Intel, die MCU1 auf Arm. D.h. sie hat eh ein anders kompiliertes Betriebssystem.
CKO könnte natürlich auch Recht haben mit den Adressleitungen, dann kann man leider echt nichts machen.

gut zu wissen das wir einen in der „Nähe“ (Holland) haben der das EMMC Problem fixen kann.
Ist doch deutlich einfacher als Kroatien, oder über SeC von Tesla.

Wer traut sich als Erster …
Nein, Quatsch beiseite bitte dann die Erfahrungen schildern.

Die Firma in Eindhoven kann feststellen wie viele Cycle der EMMC Chip erreicht hat.

Hier die Antwort:
„One newer cars with Hynix H26M42002GMR or H26M42003GMR there is a possibility to see how much erase cycles the chip has done by accessing service/developer screens on the mcu, this can be done over ethernet if you have the matching hsd/fakra cable.
These Hynix chips are rated for 3000 cycles, so if your chip would report 2000 cycles done then the lifetime is already at 66%.
But having that information really doesn’t say much since these chips can last shorter (or longer) then the rated cycle life.“

Richtig kundenfreundlich seitens Tesla wärs nun, wenn man beim SeC-Besuch Auskunft über diese Zahl erhalten könnte…

3.000 Zyklen sind Quatsch. Schreibzyklen habe ich im Hynix-Datenblatt nicht gefunden!! Beim 1Gb Flash von Hynix sind 100.000 angegeben.

Üblich sind 100.000 Schreibzyklen für Flash wie eMMC. Das entspricht auch der Zyklenfestigkeit der SwissBit-Speicher. Der Hynix hat ein eingebautes „wear levelling“. Das funktioniert nur, wenn die Partitionen kleiner als der physikalische Speicher sind. Es funktioniert ebenso nicht, wenn der Speicher mit z.B. Furzmode oder längst vergessener Ziele vollgemüllt ist.

Ich glaube eher nicht, dass der Speicher ein ein Alterungsproblem hat (Datenblatt: 10 Jahre). Es sind wohl eher die Schreibzyklen.

Möglicherweise wird das eMMC vom Linux-System auch als Auslagerungsspeicher wegen des mglw. zu kleinen RAM verwendet. Dann ist es - in Verbindung mit einer zu kleinen Speichergrösse - schneller hinüber.

Es stellen sich daher folgende Fragen:

A) Sind eher Fahrzeuge mit hoher Laufleistung >100Mm durch mehr Schreibzyklen x km betroffen?
B) Sind eher Fahrzeuge mit „Autopilot“ durch Tesla-Entwicklungslogging betroffen?
C) Kombination von A & B?

Das würde helfen, die Dringlichkeit der Massnahme besser einzuschätzen. Eine Fahrt im Frühjahr nach „Holland“ zur Tulpenernte stelle ich mir angenehmer vor, als eine Fahrt im Winter über die Alpen auf den Balkan.

Es ist nmE. in jedem Fall sinnvoll, einen grösseren Speicher (16 / 32 / 64Gb) mit der bestehenden Partitionsgrösse zu verwenden.

PS: Meine MCU benötigt jetzt nach einem Reset ca. 4 min zum booten. Da fängt der Fahrer plötzlich an zu schwitzen. Ich meine mich zu erinnern, dass das früher mal 1 Minute gedauert hat.

„Üblich“ gibts nicht, da sich die Zyklenfestigkeit von SLC bis hin zu QLC um Größenordnungen unterscheidet und maßgeblich auch von der Strukturgröße abhängt - älter (größer) ist dabei von Vorteil. Alle Chips einer Bezeichnung sollten aber identisch gefertigt sein, da ist dann via Prozessoptimierung wieder der Jüngste der wohl Beste.
H26M42003GMR soll nach kurzer Suche in der allwissenden Müllhalde 20nm-MLC sein, liegt also definitiv WEIT unter 100k Zyklen, egal wie Highend der eingruppiert ist. 3k ist nicht völlig unrealistisch. Ein Link zu deinem Datenblatt wär interessant - meine 20nm kommen hierher: ftp://62.16.43.145/Datasheets/RKeMMCSup … _06_15.pdf
Wear Levelling profitiert von Overprovisioning, also einer bewusst freigehaltenen Menge (die auch als solche erkennbar ist, u.a. Verschlüsselung kann das völlig aushebeln!), kann aber auch ohne. Man kann jetzt nach der exakt nutzbaren Partitionsgröße fragen, aber typischerweise geht zumindest der Unterschied zwischen GiB und GB als Puffer an den Controller und kann gar nicht genutzt werden. Das ist bei 4G(i)B halt auch nur bescheiden viel, verglichen mit z.B. ner 960GB-SSD, die intern mindestens 1TiB und somit 140GB Rangierfläche hat.

Ich hatte den Eindruck, dass man bei den Schreibzyklen da wohl ein oder zwei Nullen vergessen hat. Das ist ja schlimmer als befürchtet.

Der Chip scheint zu einer 26nm-Familie zu gehören. Ich hatte ein Datenblatt aus der unendlichen Weite des www https://induktionserwaermung.de/pdf/Tesla%20MCU%20Emmc%20HYSCS05784-1.pdf gefunden. Hier ist der industrielle Speicher …1FMR beschrieben. Verbaut ist …3GMRA, angeblich Automotive-Line. Die Temperaturgrade sind aber gleich.

Am liebsten wäre mir, wenn statt des BGA ein Adapter für einen Wechselspeicher möglich wäre, z.B. eine SD-Karte. So könnte man bei einem dreckigen Update den Wagen wieder sauber machen. Es gibt ein Bild des Tegraboard, auf dem die D0…D3 markiert sind. Das wäre kompatibel mit den 4-Bit SD-Karten. Wenn D5…D7 angeschlossen sind, sieht es mit SD-Karten schlecht aus.

Okay, also falls die ähnlich sein sollten, ist auf Seite 51 die Größe gelistet: E74000h Sektoren für den 8GB-Chip, d.h. exakt 7400MiB nutzbar. Bei 8GiB interner Größe (diskutabel) sind dann 792MiB oder 9,7% reserviert, was eigentlich schon ganz anständig klingt. Ich glaube nicht, dass eine Einzeldatei im System auch nur annähernd so groß ist, also immer sicher geschrieben oder geändert werden sollte. Wenns dann mal so weit ist, hats der Chip auch wirklich endgültig hinter sich.

So gut ein tauschbarer Systemspeicher auch klingt, hochwertige eMMC dürften einfacher zu finden sein als hochwertige SD-Karten. Zumal man sich mit einem SD-Sockel wieder Mechanik einfängt, die neben stärker belasteten Lötstellen auch ihrerseits nachgeben kann. Und das auch noch dem Käufer zugänglich zu machen schreit nur nach schlechter Presse, weil irgendwer in sein 100k€-Auto eine 1,99€-Karte vom Grabbeltisch steckt, die dann Ladegeschwindigkeiten wie ein Diskettenlaufwerk hat.

Hello. Sorry for English, my German writing is not so good (I can understand it just fine though)

I am that guy from Eindhoven. Yes I work from home, no I don’t work in a „Keller“ :wink: (I don’t like the word „Bastler“ by the way, but maybe I interpret that wrong)
Background: I have been doing BGA repairs (reflow & reball) since Xbox360/PS3 era, and later also phone repairs. But I have stopped this years ago because it took too much time and my other work got preferred over this (very time consuming) repair work.

But since I had the famous „black screen“ on my 2015 Model S myself earlier this year I have started to do a lot of research (especially about the software Tesla uses on the MCU) and was able to repair my own car. Took many hours, days, weeks of reading and trial-and-error.

a) The soldering of the chip is the actually easy part, the most difficult is
b) reading the data of the chip before desoldering it (since aging chips tend to die very easy when heating them up) and
c) making the right firmware/filesystem corrections of the image to write to the new chip.
For problem b) I have developed a method to read the old chip via software (different from the Croatian who uses a relatively time consuming hardware/in circuit read method). I can also offer this read service remotely to any owners or repair shops that would like to read the chip before desoldering it.
For c) I have managed to understand how the Tesla MCU works and what firmware and other files should be where etc. This also includes knowledge on how to „root“ the MCU and be able to see and do things normally only Tesla service technicians can see or do.
I have access to almost all firmware versions that are known, and can correct almost all of this data when the old emmc chip is corrupted.

The only thing I cannot (fully) repair is when the chip is completely dead or unreadable. There are two unique/essential key/certificate files (total of about 3kB) which reside on the emmc. When those two files are lost or unreadable then the car will not connect to tesla vpn anymore (no app, updates, spotify, etc). Tesla will not give you these files or help in any way if you replace the emmc yourself, they can only offer the full MCU replacement (± €3000). But in theory you could write a emmc image without these files and have a perfectly drivable car (but a MCU with mentioned functions missing).

3000 P/E cycles is actually the industry accepted rating for MLC.
Also the emmc-health.sh script which is on all Tesla firmwares since early 2019 mentions this cycle number:

if has_quirk "jedec5life" ; then # Estimate "A" is typically for SLC health life_est_a=$(read_ext_csd_slices 268) # Estimate "B" is typically for MLC health life_est_b=$(read_ext_csd_slices 269) pre_eol_info=$(read_ext_csd_slices 267) else if has_quirk "hynixhealth" ; then # simulate JEDEC 5 life time info using 3000 P/E cycle limit # SLC data doesn't seem valid in the field, so don't even try # to set life_est_a # For MLC, round to nearest percentage using erase cycle counts if [ "${AVG_BLK_ERASES}" != "" ] ; then life_est_b=$(printf "0x%02x" $((AVG_BLK_ERASES/300+1))) fi fi fi
Google it, and you will find it on many websites like:
https://www.datalight.com/blog/2013/07/23/what-is-industrial-grade-emmc/
http://www.ni.com/product-documentation/10126/en/

There are many processes that add cycles to the emmc chip. Like google maps cache, streaming (tunein/spotify) cache, system logs (which have been greatly reduced since 2019.32.12.7), firmware updates, etc.
In general the longer the car has been used the greater the impact it will have on the emmc chip.
Temperature is also a factor, cars in hot countries like Spain will experience emmc failure earlier then in Norway for instance.
But both will fail at some point in time, even with the recent reduction in logging.
My own car failed after only 3+ years and about 130.000km. But there are also cars that are already 6 years old and over 300.000km on it without any (detectable) emmc issues. It is like a Russian roulette: you know it will fail someday, but not when.

I normally use the SFEM016GB1EA1TO-I-GE-111-E08 chip from Swissbit (a German chip producer if I’m correct). This chip has a 16GB raw capacity but is set to pSLC mode which reduces the netto/available size to 8GB (exactly the same size as the original Hynix chips uses) but has a 7 times better expected cycle life (20.000 P/E). Combine this with the reduced logging Tesla introduced in 2019.32.12.7 and you can expect a new life time that is longer then the car will ever see (in most cases). Most cars will have crashed, broken down, or sold before the emmc will cause any problems again.
It has very little to no use to use even bigger chips, but I have used 32GB and even 64GB chips on customer request.

You don’t want to do that, that would involve modifying the pcb and adding a (micro)sd adapter, which could introduce other problems. Think of things that happen in cars like vibrating, large variance in temperature, moisture, etc.
Replacing the emmc chip with a better/industry grade chip would be the best solution, you will never have to worry about the chip going „Kaputt“ again :wink:

I will try to follow this thread the coming time, if anyone has questions about emmc repair or Tesla firmware please let me know.

1 „Gefällt mir“

Thanks for your introduction :slight_smile: It is a pleasure to see that there are people around knowing what can be done and how it has to be done :slight_smile: Due to my regular trips to the NL I will also make a stop at Eindhoven in January 2021 whan my car is out of warranty to get a new chip :smiley: :smiley:

Ich habe einen Termin bei ihm gemacht fuer den 23. Dezember und werde dann berichten.

Yes, great to read that LuckyLuke is relatively close and absolutely competent!

Hallo @LuckyLuke, Du bist ja schon ein Tesla-Veteran – seit 2013 in diesem Forum registriert! Nachträglich nochmal ein Herzliches Willkommen und vielen Dank, dass Du Dich in diesem Thread zu Wort gemeldet hast!

@LuckyLuke: Ich hatte deine Antwort 1:1 gepostet. Vielen Dank für die ausführliche Erklärung.

@LuckyLuke: I Have a 2015 Model S85 D with about 70Kkm, still under extended Tesla Allianz Warranty, would it be advisable to read out and secure EMMC Data in case it would fail at some time?

How much would that cost me?

Edit: Spelling

@LuckyLuke: I second this.
I’m just unsure about the mentioned keytab file / certificates. Do you have any clue when these certs are expiring?
Or are they getting raplaced regularily?

…in this case it makes less sense to save a copy of them just in case.

Awesome Job, Luke! This definitely adds another layer of sustainabilty to owning a Tesla, one that the mothership is not willing to offer.

I guess it does not make sense to just create a backup of the still-working chip to then use the crucial files once the chip may fail a year later, or does it?

For me to be able to read the emmc contents I would have to open the dashboard, remove the mcu from the car, open the mcu and take out the Tegra cpu board and read it in my prepared testbench mcu. Estimate time spent: 2-3 hours.
When you are that far in disassembling it would make little sense in only reading the emmc and putting all back in the car.
It would be much smarter to replace the emmc chip at that point. Total estimate time spent: 4 hours.

In your case since you have an extended warranty until 8years/160.000km it would make little sense in doing this procedure before your warranty expires.

The certificate expires after about 3 1/2 years. But sometimes it gets renewed early, so it doesn’t necessarily mean that a early 2018 car will get a new certificate in late 2021, it could happen sooner.

Thanks LuckyLuke this all makes sense.

I’m off this topic till Nov 2022 and hope my chip fails within this time (to get replaced by Tesla, paid by Alliantz and be save another 5+ years)

@LuckyLuke: Guter Job und Lieber ein Bastler der greative Lösungen findet, als 10 Ingeneure die nur in Ihrem Bereich nach Lösungen suchen!
Mit meinem 90D aus Dezember 2015 werde ich kein Russisches Roulette spielen.
Der letzte Reset ist zwar diesen Frühling gewesen also scheint bei mir das Problem nicht akut zu sein, aber…
Muss noch meinen Urlaub checken denke aber das ich einen Termin (falls passend) im Februar nehme.