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

Warning, rebooting v10 on MCU1 while driving

This site may earn commission on affiliate links.
I have over 11,000 miles on my Model 3 with no spontaneous reboots. Maybe it is an S/X thing.
I'm pretty sure it is illegal to drive without a speedometer no matter what the cause.
My advice: If you ever get pulled over for no speedometer, don't tell the officer that you initiated a reboot and knew it would go blank.
 
  • Like
Reactions: RichieM
I have over 11,000 miles on my Model 3 with no spontaneous reboots. Maybe it is an S/X thing.
I'm pretty sure it is illegal to drive without a speedometer no matter what the cause.
My advice: If you ever get pulled over for no speedometer, don't tell the officer that you initiated a reboot and knew it would go blank.
Give it time, when Model Y+MCU3 and your Model 3 will be forced to run software written for that.
 
It'd be interesting to try driving an S without power steering or power brakes. I can recall an emergency stop when I was driving a '52 R type Bently (wasn't my car) when power assist and hydraulics failed and I had just the cables -

Just cover your car’s radar/sensors + camera on the windscreen with muck or any soil and give it a drive, you will have non-functional safety systems and a joy of your muscles power...
 
Seriously, rebooting while driving? With the family? What makes you think that NONE of the safety systems (like airbags and seat belt tensioners) are not affected or disabled during a reboot?

You might not needing it i the States but if you travel long distances, here in Europe between different countries your MCU will not be able to continue to handle your trip and other activities and as of this it’s required to make that reboot on wheel, just to make sure you keep your foot off the brakes while using your thumbs...
 
I reckon the MCU v1 eMMC memory turned out to be hopelessly under sized and technically inadequate for the demands of the application. Hence the need for MCU v2. The core functions (ignore farting and other pointless 'features') like GPS, sentry, update handing, car systems control) are no different between early cars and cars to be released 5 years from now.

There are so many examples of what can go wrong when an over loaded MCU, quite possibly with unreliable eMMC memory gets rebooted, that it is pointless saying that this is somehow OK or even correct functioning. When MCUs self reboot, I bet that quite often it's because they have got into a state that they just can't carry on working and the reboot is not a controlled system response so much as an unavoidable and unpredictable one.

Since the eMMC chip in MCU 2 is very similar to MCU 1, it's reasonable that it can easily suffer similar issues.

Don't Lemon Laws come into play here (in the US)? I mean rapid fogging of windshield, no access to most ancillary equipment, unpredictable behavior, potential loss of speed display...... Even possibility of car's driving characteristics changing significantly / suddenly.
 
Last edited:
I reckon the MCU v1 eMMC memory turned out to be hopelessly under sized and technically inadequate for the demands of the application. Hence the need for MCU v2.
Not really. MCU1 worked well running v5, v6, v7 (though it was getting slower as versions went up). The features added to the MCU since then are mostly superficial, and designed for MCU2, therefore neither optimized for MCU1 or written with resource consideration of MCU1. It's like forcing latest Windows 10 to run on laptop form 2012 - it ran Windows 7 really well, but Windows 10 is crawling and some features don't work at all.

Even Microsoft, the king of backwards compatibility, doesn't support PC hardware from over a decade ago, because they know the cost of support that far back is exponential. Lucky for Microsoft, PC's lifecycle is not over a decade - nobody expects latest Windows to run on a 10 year old PC. Yet Tesla will have to support it since cars live longer than 10 years. This will become an ever-increasing problem for Tesla.
 
Last edited:
  • Like
Reactions: Droschke
MCU1 worked well running v5, v6, v7 (though it was getting slower as versions went up). The features added to the MCU since then are mostly superficial, and designed for MCU2, therefore neither optimized for MCU1 or written with resource consideration of MCU1.

I got the impression that apart from 32 Gb eMMC vs 8Gb eMMC there isn't a huge difference from a processing standpoint between MCU 1 & 2. And certainly that the volume of traffic going through the eMMC's pretty much dictated early failure (certainly in terms of typical vehicle component life expectancies and may be by any other measure).

Specifically, older software was running on newer cars (at the time) so eMMC errors less likely, no? And usually as feature sets grow and owners actually use their cars more, GPS, vehicle log & other data is pouring through the eMMC, using up its reliable service life.

I saw some MCU v2 cars (one or 2 on here?) that have had the same sort of problems that COULD be partly attributed to eMMC data errors / failure.
 
  • Informative
Reactions: Droschke
Rebooting MCU while driving is absolutely safe.
No driving or safety functions are performed by the MCU, so nothing changes in the driving behaviour or safety if the MCU is down.
Also, speedometer for model S/X is on IC, not MCU, so even that angle is covered.
Rebooting IC is also totally safe, but for loosing speedometer for a few seconds.

As already reported, passing a border is rather common in EU, and many times it means a reboot is necessary to force the map to calculate the correct drive to your next destination.
 
Rebooting MCU while driving is absolutely safe.
No driving or safety functions are performed by the MCU, so nothing changes in the driving behaviour or safety if the MCU is down.
Also, speedometer for model S/X is on IC, not MCU, so even that angle is covered.
Rebooting IC is also totally safe, but for loosing speedometer for a few seconds.

As already reported, passing a border is rather common in EU, and many times it means a reboot is necessary to force the map to calculate the correct drive to your next destination.
I was thinking more about updates.
It sounds as though updates get staged in the MCU where I expect they are validated before processing further. But at some point the update gets handed off for final installation. If something goes wrong at that point, surely the results will be unpredictable.

f205v - I understand there are only 3 'computers' on the model 3: Left, center and right. So what controls the safety systems and how do we know what reboots and what doesn't?

As owners / drivers we shouldn't need to give this a second thought, but given how there seems to be a broad range of vehicle behaviours when attempting updates, it does make you concerned.

Especially updates that appear to fail or stall and require further soft or hard reboots to get back to 'normal.'
 
f205v - I understand there are only 3 'computers' on the model 3: Left, center and right. So what controls the safety systems and how do we know what reboots and what doesn't?
From what I know, also in model 3 the car computer is totally separate from the MCU. So you should be able to perform a reboot of the MCU without any consequence to the car's driving dynamics and safety. Only issue is that you will lose speedometer for a few seconds, which may be illegal.
 
Man, that sucks. I once had a driving thumb wheel reset go wrong - after the reset I had all sorts of warnings about stability control unavailable, no regen, etc. Was on my old classic P85. Had to pull over and do the Power Off option. I no longer reset while driving anymore.

This! I’d never entertain a reset while driving. The thought of something going wrong that I can’t be in more control of, and me bringing harm to another, as well as myself, really gives me pause.
 
Combining a failable human with a failable computer can give permutations far beyond the capabilty of software engineers to make 100% fail safe.

Rebooting, with your family on board, at highway speeds is something that would give most people (but obviously not all) pause.

Nobody, outside Tesla, knows exactly what is going on with every permutation when a reboot is instigated.

We all know that just because Elon tweets something, that does not always make it so.

Believe it is foolish to reboot at high speeds, with precious cargo. Much safer to wait for a bit, or pull over to reboot.
 
whitex... How old is your MCU?
The first signs of my MCU (eMMC) failure were: corruption in the map display, reboots taking longer after each reset, different features not working correctly after each reboot. It ended up with reboots taking well over a hour, followed after a day or so with not rebooting at all.
 
The first signs of my MCU (eMMC) failure were: corruption in the map display, reboots taking longer after each reset, different features not working correctly after each reboot. It ended up with reboots taking well over a hour, followed after a day or so with not rebooting at all.

This is exactly the behaviour I think more and more owners are likely to experience as the MCU memory gets older / has been written to many more times / is used to hold larger non-changing amounts of data (leaving less room for wear-levelling to be implemented and hastening the chip's demise).

What 'features' were effected?
 
I got the impression that apart from 32 Gb eMMC vs 8Gb eMMC there isn't a huge difference from a processing standpoint between MCU 1 & 2. And certainly that the volume of traffic going through the eMMC's pretty much dictated early failure (certainly in terms of typical vehicle component life expectancies and may be by any other measure).

Specifically, older software was running on newer cars (at the time) so eMMC errors less likely, no? And usually as feature sets grow and owners actually use their cars more, GPS, vehicle log & other data is pouring through the eMMC, using up its reliable service life.

I saw some MCU v2 cars (one or 2 on here?) that have had the same sort of problems that COULD be partly attributed to eMMC data errors / failure.
Of course MCU2 has more processing power. MCU1 uses an SoC released in 2011 (so think iPhone 4S timeframe and processing power). MCU2 uses current generation Intel Atom x86. So, running v10 on MCU1 is like running IOS13 on iPhone 4S.

EMMC logging was just bad design, or a decision made to sacrifice reliability in exchange for ability to debug beta cars. I suspect it was not a conscious decision, but rather an omission, given Elon's "best process is no process" attitude.

As for EMMC failures, well, they fail for different reasons. Wear is definitely an issue, but it can fail due to production quality issues (nothing is perfect) or even when sitting unpowered in hot environment for a while (possibly offset by cabin overheat protection in Teslas). An MCU2 failure today would most likely be due factors other than excessive wear.
 
  • Like
Reactions: Droschke