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.
My 2014 S screen was behaving erratically so I tried a reboot while driving a week and a half ago. It never came back on again despite repeated attempts. Ended up having to pay for a new screen/MCU. At least our local Tesla service center is easy to work with. I'd had trouble off and on with it for a few years but was always able to get back online ok. Not this time.
 
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.

a whole lotta unsubstantiated guessing go on here.
 
a whole lotta unsubstantiated guessing go on here.

I think it's more of an issue with how Linux logging works. eMMC storage is basically a memory card mounted inside the MCU. Solid state storage devices (including memory cards) have a finite limit of times data can be rewritten and rewritten to the same area on the disk. Once that limit is reached, that area is marked unusable. Seeing as how Linux out of the box generates a ton of log files (especially when running in debug mode), it can exhaust this limit.
 
  • Like
Reactions: Battpower
I’m not a techie guy, but here is my experience. I have a Model S 100D, delivered in late-December 2018. The first time I lost my display screens was while driving, when the screens blacked out without warning and, I guess, had a reboot that I did not initiate. It happened while I was passing a semi truck at 85 mph in the dark, on the I-5 freeway on my first road trip, halfway between LA and SF. Freaked me out! The second time was less spectacular, on city streets.

I learned to do a reboot in my driveway after every download I was aware of. And I never reboot while driving. Version 10 installed a few days ago. The reboot process lasted quite a bit longer than I’m used to, and the two displays seemed to flash on and off more than once. I’m now on 2019.32.12.2 for the last few days.

Concurrent with the V10 installation timeframe.....
— The phone app became unable to connect to the car. No remote AC or heater control, etc. I just now saw and updated the app, so tomorrow I’ll see if that helps.
— More broadly, the car seems to be experiencing network connection problems generally.
— I cannot seem to be able to use voice command for any navigation or GPS location function. I rely on navigation a lot, usually by voice command. This is a huge annoyance.
— I honestly can’t say what is going on with the media system. I can’t seem to use voice command to play music from any source.
— I lost the ability to stream music from my late-model iPhone. I can hear the music start, then after about five seconds or so, it just stops. Then I have to start over. This is another major annoyance.
— I don’t have or particularly want Spotify, I want the Apple Music and Amazon Music Premium services I already pay for, which are not offered. Or the music on my phone, at the very least.

There may be other things that I’m forgetting right now. Constructive comments are welcome.
 
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.

a whole lotta unsubstantiated guessing go on here.

All based on posted experiences / evidence from this forum and links to other sites from here.
 
I spoke with Tesla support on Saturday (10/19) My modem was connecting and disconnecting as we drove. He instructed me "put my foot on the brake, press and hold both scroll wheels until the screen goes black and the "T" appears on the screen." I too have rebooted while driving previously. He said "the foot on the brake" instruction was added to indicate you should NOT be driving when you do the reboot. I waited until we were parked for the night and did the reboot.

Reboot fixed the issue.
 
Our Teslas are basically a big computer. I won't do something very important systemwide on a PC such as updating firmware while my important spreadsheet is up on the screen. I always update the firmware in the garage. As with any firmware update on any electronics, a wrong block of data entering the pipeline "can" potentially brick it. Not going to happen if I'm driving the Tesla.
 
I’m not a techie guy, but here is my experience. I have a Model S 100D, delivered in late-December 2018. The first time I lost my display screens was while driving, when the screens blacked out without warning and, I guess, had a reboot that I did not initiate. It happened while I was passing a semi truck at 85 mph in the dark, on the I-5 freeway on my first road trip, halfway between LA and SF. Freaked me out! The second time was less spectacular, on city streets.

I learned to do a reboot in my driveway after every download I was aware of. And I never reboot while driving. Version 10 installed a few days ago. The reboot process lasted quite a bit longer than I’m used to, and the two displays seemed to flash on and off more than once. I’m now on 2019.32.12.2 for the last few days.

Concurrent with the V10 installation timeframe.....
— The phone app became unable to connect to the car. No remote AC or heater control, etc. I just now saw and updated the app, so tomorrow I’ll see if that helps.
— More broadly, the car seems to be experiencing network connection problems generally.
— I cannot seem to be able to use voice command for any navigation or GPS location function. I rely on navigation a lot, usually by voice command. This is a huge annoyance.
— I honestly can’t say what is going on with the media system. I can’t seem to use voice command to play music from any source.
— I lost the ability to stream music from my late-model iPhone. I can hear the music start, then after about five seconds or so, it just stops. Then I have to start over. This is another major annoyance.
— I don’t have or particularly want Spotify, I want the Apple Music and Amazon Music Premium services I already pay for, which are not offered. Or the music on my phone, at the very least.

There may be other things that I’m forgetting right now. Constructive comments are welcome.
Do a complete power down from the touch screen and it should clear up. It did for me.
 
I spoke with Tesla support on Saturday (10/19) My modem was connecting and disconnecting as we drove. He instructed me "put my foot on the brake, press and hold both scroll wheels until the screen goes black and the "T" appears on the screen." I too have rebooted while driving previously. He said "the foot on the brake" instruction was added to indicate you should NOT be driving when you do the reboot. I waited until we were parked for the night and did the reboot.

Reboot fixed the issue.
Foot-on-the-brake reset has been a deeper reboot instructions for a while - supposedly the MCU detects if your foot is on the brake when booting and performs re-initialization of things normally skipped during regular, non-brake-hold, thumb-wheel reset.
 
Last edited:
This is just warn folks used to rebooting their MCU1 while driving (I used to do that every few drives, when the browser would stop working or some other artifact - Tesla software is not famous for its stability). After applying v10 I was driving with the family to dinner tonight. Browser (now taking up most of the screen :mad:) was dead as usual so I went for the thumbwheel reset. What a disaster!

First, it took 5+ minutes to reboot, WTF? The front windshield started fogging up, so I had to open windows to continue to drive, which of course was uncomfortable for everyone since it's fall and we don't live in California. Second, Thumbwheel reboot used to only reboot the big screen (MCU1), however this time, after few minutes of dark main screen, my instrument cluster went dark too! o_O So now I'm driving a car without HVAC or any screens at all, not even a speed indicator. Now, the cluster was only off for a short time (30-60 seconds maybe) but it seems like forever when you don't expect it. When it came back on it has messed up controls but at least you could see most indicators. Even once the main screen came back on, it still took a bit before it was responsive enough to turn on windshield defrost.

I so wish Tesla would keep MCU1 on v8 with security patches only. My car gets worse every update.


I rebooted my Model 3 while driving about two weeks after I got it in late 2018. I did not realize there are two levels of reboot - wheel buttons only and wheel buttons with brake pedal depressed. Since I was driving, I may have had the brake pedal depressed when I attempted the reset. That would have initiated a deeper reboot. After that the screen went blank and never came back. The cabin heater was running with no way to turn it off. The reboot happened Friday evening and it was Sunday morning before Tesla could arrange a pickup. They replaced the computer under warranty although I caused the problem. One of the repair technicians said the screen computer interfaces with the drive train computer and should never be rebooted while driving. My brother has a 2015 S that he has rebooted while driving and I have seen a YouTube video of someone rebooting a Model 3 while driving. I have to conclude that the cars can be rebooted while driving without consequence some or most times but it can cause problems and rebooting should not be done while driving.
 
  • Informative
Reactions: beths11
I have to conclude that the cars can be rebooted while driving without consequence some or most times but it can cause problems and rebooting should not be done while driving.
If that was the case there would have been a hardware interlock, unless car is in "Park", do not allow reboot. Not that hard to do, and Tesla had plenty to time to learn that from Roadster, Model S and Model X before Model 3 was designed. Also, if Tesla was to state that rebooting while driving was unsafe, they would have to recall all S and X cars, as they reboot on their own while driving (speaking from experience of owning 4 Model S cars, so it's not "just my car", I don't follow Model 3 closely).
 
Our Teslas are basically a big computer. I won't do something very important systemwide on a PC such as updating firmware while my important spreadsheet is up on the screen. I always update the firmware in the garage. As with any firmware update on any electronics, a wrong block of data entering the pipeline "can" potentially brick it. Not going to happen if I'm driving the Tesla.
Are you saying any Tesla that reboots itself (without driver initiating it) while driving is a safety hazard and therefore should be immediately recalled?
 
Just as Elon pointed out about using simulation to test FSD being like marking your own exam paper, you can't design system testing to deal with every (impossible) combination of factors that you can dream up. Because you can't dream them up!

I'm not sure what your point is, exactly.
Yes, you need real-world driving to train the system.
But you ALSO need fabricated synthetic simulated data to augment that real-world.
Because I CAN dream up scenarios that are too infrequent or impossible or unsafe to stage and capture.

For example, I'm driving in the left lane on a freeway boxed in with cars all around me and a semi trailer detaches from the truck ahead of me. How many of those are you going to capture on video? And what if it was at dusk with the sun pointing right in to the camera? And in a construction zone with narrow lanes. And there was a light rain?
This happened to a friend of mine the day before his wedding. (just the trailer detaching)
Car was totaled. This was pre-airbag days. He was lucky.
 
I'm not sure what your point is, exactly.
Yes, you need real-world driving to train the system.
But you ALSO need fabricated synthetic simulated data to augment that real-world.
Because I CAN dream up scenarios that are too infrequent or impossible or unsafe to stage and capture.

For example, I'm driving in the left lane on a freeway boxed in with cars all around me and a semi trailer detaches from the truck ahead of me. How many of those are you going to capture on video? And what if it was at dusk with the sun pointing right in to the camera? And in a construction zone with narrow lanes. And there was a light rain?
This happened to a friend of mine the day before his wedding. (just the trailer detaching)
Car was totaled. This was pre-airbag days. He was lucky.

The OP was about system behavior when rebooting. The discussion has drifted around possible causes of rebooting / unpredictable behavior. Yes, Elon's point about simulation related to FSD, and I also agree that real world data is essential to broaden cases covered through simulation.

My point was related not to self driving at all, but purely about the statements that 'it is safe to reboot while driving' and 'there is no way xyz systems in the car can be effected'. When you are talking about systemic problems like unreliable eMMC behavior (due to aging, hardware or software design, extreme / unintended use patterns - whatever) then it becomes very difficult to a) gather meaningful diagnostic evidence if you focus on the myriad of symptoms and b) predict with verifiable certainty exactly how the system as a whole may behave.

I was relating the very random system behavior that could come from eMMC issues to the very random and unpredictable conditions that you need real world miles & data to 'teach' AI in the FSD world.
 
I have been in IT and IT management for over 40 years. I have seen most everything and many systems come and go, and others grow to take over the industry. I see very normal system development going on with the Tesla OS and especially the eMMC. I don't know how many times in my career I have heard an IT tech tell me these words "that should not have happened" when we had an unexpected outage caused by humans. And all outages can trace their origin back to human error with very few exceptions. That being said, I never reboot any aspect of the car unless I am pulled over and parked. If it does it while I am driving I am going to try and get over so I can stop the car till it finishes.

I am actually very encouraged by how Tesla is doing this software development. I know that this process they are using works the fastest and the best.

Just as a thought, the Apollo 11 had a computer controlling the decent to the Moon's surface from 50,000 feet and it crashed 5 times in the last 7 minutes with unknown 1202 errors that Aldrin had no clue what they meant. He kept driving too. They missed their landing site by 7 miles because of drift from a computer that was overloaded. Turned out to be human error too.
 
  • Like
Reactions: f205v and Battpower
Just as a thought, the Apollo 11 had a computer controlling the decent to the Moon's surface from 50,000 feet and it crashed 5 times in the last 7 minutes with unknown 1202 errors that Aldrin had no clue what they meant. He kept driving too. They missed their landing site by 7 miles because of drift from a computer that was overloaded. Turned out to be human error too.
I think you may like this:
Inside the Apollo Guidance Computer's core memory
On that blog you will find a number of post specifically dedicated to the Apollo guidance computer.