Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Preventive eMMC replacement on MCU1

This site may earn commission on affiliate links.
Yes we recently had a car which had scheduled charging, and the car was stuck in non charge mode, It would not charge 240 or supercharge. I suspect chademo would also not start... It actually said waiting for scheduled start when at the supercharger. After pulling the fuse, the car started charging 240 also. Will test more, this may be a solution.
My screen is black from yesterday now : when i try to supercharge, it won't start.... big sweat... i simply remove and take back the MCU fuse, and then the supercharge was working.... once at home, i try the home charge and itt's working normally too... if this tip can be usefull for someone else...
 
  • Informative
Reactions: alloverx
My screen is black from yesterday now : when i try to supercharge, it won't start.... big sweat... i simply remove and take back the MCU fuse, and then the supercharge was working.... once at home, i try the home charge and itt's working normally too... if this tip can be usefull for someone else...

yes that fuse pull can reset things. It can also cause a dyeing eMMC to overwrite it’s files. It’s a tough choice to make. I do recommend everyone do preventive maintainable upgrades.

glad you were able to get home safe.
 
  • Like
Reactions: Akikiki
I don't see a lot of risk in attempting to fix a failed ECU. Soldering the eMMC would be about it. Copying the data off the old eMMC to the new one shouldn't be a big issue. Caveat: I've been a Linux tech since 2002.

Depends how you do it. If you want to salvage the certs, not many chances may be left. However your correct as there is nothing that Tesla wont restore with a new mcu.
 
  • Like
Reactions: Akikiki
Depends how you do it. If you want to salvage the certs, not many chances may be left. However your correct as there is nothing that Tesla wont restore with a new mcu.

What do you mean by "there is nothing that Tesla wont restore with a new mcu." ?

There is possibly another entire way to fix this problem, if you have enough access to the Linux system and by that I mean the boot loader.

In Linux you can set up the boot loader to put (locate) different parts of the file system on different physical or logical "devices". So theoretically if one has access to the boot loader and to a file system interface, possibly an SD drive, USB port, that sort of thing, you could connect a new hard drive device to the file system, transfer the contents of the eMMC to the new device and set up the boot loader so that /var now goes to the new device, instead of the eMMC.

Linux is an extremely versatile operating system if you get access to it.
 
Playing high bitrate streaming radiostations 24/7 (camper mode, anybody?) would have some effect too, I’d guess.
Depends what is being written to /var. If it is just diagnostics info, probably a lot of that can be turned off if you have access to the OS.

On the machine I'm using right now, (Fedora 32) the top level /var directory looks like this:

ls /var
account cache db ftp kerberos local log nis preserve snap tmp yp
adm crash empty games lib lock mail opt run spool www

Here is /var/log on my machine, a workstation.

dnf is the software package manager on Fedora.


ls /var/log
anaconda dnf.librepo.log-20200607 hawkey.log private
atop dnf.log hawkey.log-20200517 README
audit dnf.log.1 hawkey.log-20200524 samba
blivet-gui dnf.log.2 hawkey.log-20200531 secure
boot.log dnf.log-20190630 hawkey.log-20200607 secure-20200517
boot.log-20200505 dnf.log-20190715 httpd secure-20200524
boot.log-20200506 dnf.log-20190721 java_install.log secure-20200531
boot.log-20200513 dnf.log-20190728 journal secure-20200607
boot.log-20200514 dnf.log.3 kdm.log speech-dispatcher
boot.log-20200521 dnf.log.4 kdm.log-20200110 sphinx
boot.log-20200522 dnf.rpm.log lastlog spooler
boot.log-20200523 dnf.rpm.log.1 libvirt spooler-20200517
btmp dnf.rpm.log.2 maillog spooler-20200524
btmp-20200601 dnf.rpm.log-20190630 maillog-20200517 spooler-20200531
chrony dnf.rpm.log-20190715 maillog-20200524 spooler-20200607
cluster dnf.rpm.log-20190721 maillog-20200531 sssd
cron dnf.rpm.log-20190728 maillog-20200607 swtpm
cron-20200517 dnf.rpm.log.3 mariadb tallylog
cron-20200524 dnf.rpm.log.4 messages wtmp
cron-20200531 dpkg.log messages-20200517 wtmp-20191216
cron-20200607 firebird messages-20200524 Xorg.0.log
cups firewalld messages-20200531 Xorg.0.log.old
dnf.librepo.log fsck_hfs.log messages-20200607 Xorg.9.log

ls /var/log -al
total 81124
drwxr-xr-x. 24 root root 4096 Jun 8 19:15 .
drwxr-xr-x. 22 root root 4096 May 12 23:57 ..
drwxrwxr-x. 2 root root 4096 Oct 21 2016 anaconda
drwxr-xr-x. 2 root root 4096 Jan 28 05:26 atop
drwx------. 2 root root 4096 May 23 13:39 audit
drwxr-xr-x. 2 root root 4096 Apr 21 12:16 blivet-gui
-rw-r--r--. 1 root root 0 May 23 00:01 boot.log
-rw-r--r--. 1 root root 42622 May 5 00:00 boot.log-20200505
-rw-r--r--. 1 root root 23026 May 6 00:00 boot.log-20200506
-rw-r--r--. 1 root root 2861260 May 13 00:00 boot.log-20200513
-rw-r--r--. 1 root root 49867 May 14 00:01 boot.log-20200514
-rw-r--r--. 1 root root 25989 May 21 00:01 boot.log-20200521
-rw-r--r--. 1 root root 423887 May 22 00:01 boot.log-20200522
-rw-r--r--. 1 root root 21431 May 23 00:01 boot.log-20200523
-rw-rw----. 1 root utmp 0 Jun 1 00:01 btmp
-rw-rw----. 1 root utmp 2304 May 25 01:25 btmp-20200601
drwxr-xr-x. 2 chrony chrony 4096 Jan 28 07:04 chrony
drwxr-xr-x. 2 root root 4096 Apr 27 01:30 cluster
-rw-------. 1 root root 13499 Jun 8 23:01 cron
-rw-------. 1 root root 43557 May 16 23:01 cron-20200517
-rw-------. 1 root root 72093 May 23 23:01 cron-20200524
-rw-------. 1 root root 46900 May 30 23:01 cron-20200531
-rw-------. 1 root root 47544 Jun 7 00:01 cron-20200607
drwxr-xr-x. 2 lp sys 4096 May 26 00:00 cups
-rw-------. 1 root root 47216 Jun 8 23:07 dnf.librepo.log
-rw-------. 1 root root 1034305 May 16 23:16 dnf.librepo.log-20200517
-rw-------. 1 root root 369297 May 23 23:01 dnf.librepo.log-20200524
-rw-------. 1 root root 250209 May 30 23:30 dnf.librepo.log-20200531
-rw-------. 1 root root 193744 Jun 6 23:28 dnf.librepo.log-20200607
-rw-r--r--. 1 root root 91030 Jun 8 23:40 dnf.log
-rw-r--r--. 1 root root 1048567 Jun 8 19:15 dnf.log.1
-rw-r--r--. 1 root root 1048503 May 28 14:02 dnf.log.2
-rw-------. 1 root root 698659 Jun 29 2019 dnf.log-20190630
-rw-------. 1 root root 543509 Jul 6 2019 dnf.log-20190715
-rw-------. 1 root root 553595 Jul 20 2019 dnf.log-20190721
-rw-------. 1 root root 531727 Jul 27 2019 dnf.log-20190728
-rw-r--r--. 1 root root 1031163 May 19 17:43 dnf.log.3
-rw-r--r--. 1 root root 832650 May 12 23:57 dnf.log.4
-rw-r--r--. 1 root root 59753 Jun 8 23:07 dnf.rpm.log
-rw-r--r--. 1 root root 1048518 May 22 01:30 dnf.rpm.log.1
-rw-r--r--. 1 root root 1048534 Mar 6 21:47 dnf.rpm.log.2
-rw-------. 1 root root 138896 Jun 29 2019 dnf.rpm.log-20190630
-rw-------. 1 root root 67742 Jul 6 2019 dnf.rpm.log-20190715
-rw-------. 1 root root 92537 Jul 20 2019 dnf.rpm.log-20190721
-rw-------. 1 root root 8910 Jul 27 2019 dnf.rpm.log-20190728
-rw-r--r--. 1 root root 1048549 Nov 15 2019 dnf.rpm.log.3
-rw-------. 1 root root 1048538 Nov 5 2019 dnf.rpm.log.4
-rw-r--r--. 1 root root 0 May 12 23:07 dpkg.log
drwxr-xr-x. 2 root root 4096 Jan 28 11:36 firebird
-rw-r-----. 1 root root 211731 May 4 17:39 firewalld
-rw-r--r--. 1 root root 952 May 4 22:05 fsck_hfs.log
drwx--x--x. 2 root gdm 4096 May 5 13:12 gdm
drwxr-xr-x. 2 root root 4096 May 18 15:30 glusterfs
-rw-------. 1 root root 173601 May 27 2019 grubby
-rw-------. 1 root root 816 Jun 8 21:05 hawkey.log
-rw-------. 1 root root 4692 May 16 21:14 hawkey.log-20200517
-rw-------. 1 root root 6834 May 23 23:01 hawkey.log-20200524
-rw-------. 1 root root 3825 May 30 21:29 hawkey.log-20200531
-rw-------. 1 root root 2958 Jun 6 23:28 hawkey.log-20200607
drwx------. 2 root root 4096 Mar 31 09:20 httpd
-rw-r--r--. 1 root root 0 Nov 23 2016 java_install.log
drwxr-sr-x+ 4 root systemd-journal 4096 Feb 7 2017 journal
-rw-r--r--. 1 root root 0 Jan 10 00:00 kdm.log
-rw-r--r--. 1 root root 2118 Jan 9 17:09 kdm.log-20200110
-rw-rw-r--. 1 root utmp 293168 May 29 18:03 lastlog
drwx------. 3 root root 4096 Mar 24 09:47 libvirt
-rw-------. 1 root root 0 Jun 7 00:01 maillog
-rw-------. 1 root root 0 May 10 00:00 maillog-20200517
-rw-------. 1 root root 0 May 17 00:01 maillog-20200524
-rw-------. 1 root root 0 May 24 00:00 maillog-20200531
-rw-------. 1 root root 0 May 31 00:00 maillog-20200607
drwxr-x---. 2 mysql mysql 4096 Mar 16 07:14 mariadb
-rw-------. 1 root root 1207302 Jun 8 23:40 messages
-rw-------. 1 root root 6778787 May 16 23:50 messages-20200517
-rw-------. 1 root root 31528336 May 24 00:00 messages-20200524
-rw-------. 1 root root 13432656 May 31 00:00 messages-20200531
-rw-------. 1 root root 10680171 Jun 7 00:01 messages-20200607
-rw-r--r--. 1 root root 532 Nov 23 2019 pacman.log
drwx------. 3 root root 4096 Apr 14 11:19 pluto
drwx------. 2 root root 4096 Apr 7 02:57 ppp
drwx------. 2 root root 4096 Dec 17 2018 private
-rw-r--r--. 1 root root 1040 Apr 1 11:23 README
drwx------. 4 root root 4096 May 22 17:06 samba
-rw-------. 1 root root 0 Jun 7 00:01 secure
-rw-------. 1 root root 6319 May 14 16:02 secure-20200517
-rw-------. 1 root root 70683 May 23 13:38 secure-20200524
-rw-------. 1 root root 3239 May 29 22:37 secure-20200531
-rw-------. 1 root root 918 Jun 5 16:15 secure-20200607
drwx------. 2 root root 4096 Feb 25 03:39 speech-dispatcher
drwxr-xr-x. 2 sphinx root 4096 Jan 30 19:43 sphinx
-rw-------. 1 root root 0 Jun 7 00:01 spooler
-rw-------. 1 root root 0 May 10 00:00 spooler-20200517
-rw-------. 1 root root 0 May 17 00:01 spooler-20200524
-rw-------. 1 root root 0 May 24 00:00 spooler-20200531
-rw-------. 1 root root 0 May 31 00:00 spooler-20200607
drwxr-x---. 2 root root 4096 Jun 7 00:01 sssd
drwxr-xr-x. 3 root root 4096 Dec 17 2018 swtpm
-rw-------. 1 root root 0 Dec 20 17:22 tallylog
-rw-rw-r--. 1 root utmp 614784 May 30 02:29 wtmp
-rw-rw-r--. 1 root utmp 1051392 Dec 15 19:29 wtmp-20191216
-rw-r--r--. 1 root root 59406 Jan 9 17:09 Xorg.0.log
-rw-r--r--. 1 root root 64821 Jan 9 16:31 Xorg.0.log.old
-rw-r--r--. 1 root root 47243 Jan 9 13:41 Xorg.9.log

Some people have root access to their MCUs, right ? What does ls /var/log -al look like for them ?
 
What do you mean by "there is nothing that Tesla wont restore with a new mcu." ?

There is possibly another entire way to fix this problem, if you have enough access to the Linux system and by that I mean the boot loader.

In Linux you can set up the boot loader to put (locate) different parts of the file system on different physical or logical "devices". So theoretically if one has access to the boot loader and to a file system interface, possibly an SD drive, USB port, that sort of thing, you could connect a new hard drive device to the file system, transfer the contents of the eMMC to the new device and set up the boot loader so that /var now goes to the new device, instead of the eMMC.

Linux is an extremely versatile operating system if you get access to it.

You mentioned "I don't see a lot of risk in attempting to fix a failed ECU"

The risk is you can loose your last chance to retrieve the data. Maybe you are also good with the techniques used by advance recovery like multicom.pl, then you have much more chances.

If you loose all the data, which does not sound like an issue for you, Tesla will restore all necessary files with a MCU purchased and installed into a car from them, so "there's nothing Tesla wont restore with a new MCU"

However maybe we are talking about different things, Tesla's have many ECU's.

I'm a little too confused to be in this conversation. Sorry to be wasting your time.
 
From a risk point of view, if I understand the situation, when the MCU fails, Tesla replaces it. And unless you replace the existing eMMC with a new one, there is no other solution. So it is either try to replace it and maybe fail OR let it fail and Tesla will replace it for you and charge you accordingly. Am I right ?

Furthermore, the biggest risk is working on the first ones. Once you get the process figured out, the rest are just duplication of the process.

I have a hunch that the eMMC doesn't fail entirely. I suspect it won't write anymore and that the last file image on it doesn't pass a checksum test of some sort. The eMMC might be readable (with faulty data) even after the MCU won't boot. Such an eMMC wouldn't be good for operating the car but would be fine for testing purposes.

Do owners get to keep their old MCU ? What does Tesla do with them ?
 
From a risk point of view, if I understand the situation, when the MCU fails, Tesla replaces it. And unless you replace the existing eMMC with a new one, there is no other solution. So it is either try to replace it and maybe fail OR let it fail and Tesla will replace it for you and charge you accordingly. Am I right ?

Furthermore, the biggest risk is working on the first ones. Once you get the process figured out, the rest are just duplication of the process.

I have a hunch that the eMMC doesn't fail entirely. I suspect it won't write anymore and that the last file image on it doesn't pass a checksum test of some sort. The eMMC might be readable (with faulty data) even after the MCU won't boot. Such an eMMC wouldn't be good for operating the car but would be fine for testing purposes.

Do owners get to keep their old MCU ? What does Tesla do with them ?

Sometimes, chips come in all different conditions. Some are totally dead unless extreme recovery methods to use. Pretty much all the information you need is in this thread.

It depends on the SC. Most will charge owner $1000 core charge to keep it.

Get yourself some junk failed chips and have some fun.