Tesla infotainment system upgradeable from MCU1 to MCU2

[rnortman]

That’s quite a blanket statement that doesn’t serve anyone well without clarification. Specifically, what do you mean by this? All cars, by any manufacturer, ‘begin to die’ at 4-5 years? Only Teslas begin to die at 4-5 years?

It’s a big difference replacing a part at 4-5 years as opposed to your entire vehicle ‘beginning to die’. What statistics & evidence do you have for this statement?

He's referring to a specific problem with the flash storage on MCU1 cars wearing out due to excessive and unnecessary logging activity. When this happens the car becomes unusable until the MCU is replaced or the flash storage on the MCU is replaced. Some third parties will replace the flash chip (which is soldered on and not easily replaceable), but Tesla will only replace the whole MCU, at a cost of around US$2500 IIRC.

This problem has been well documented and reported to Tesla but they have never shown any interest in fixing it -- until recently when the problem started getting a lot of press. The fix is simple: Configure the embedded Linux OS to not log so much useless data that nobody ever accesses to the flash storage.

 

[S100D]

That’s quite a blanket statement that doesn’t serve anyone well without clarification. Specifically, what do you mean by this? All cars, by any manufacturer, ‘begin to die’ at 4-5 years? Only Teslas begin to die at 4-5 years?

It’s a big difference replacing a part at 4-5 years as opposed to your entire vehicle ‘beginning to die’. What statistics & evidence do you have for this statement?

Viper is saying that the eMMC in the Model S/Xs that have MCU1s will start to fail in 4 to 5 years.

 

[SucreTease]

They proved to be interchangeable enough. I don’t take autopilot into account yet. Need to try.

Of course not compatible)
To transfer the machine to AP3, a lot of things need to be replaced ...

@Flaminis, as you are a brand new member to these forums, and these three posts in this thread are your first and only posts on TMC, I hope you will understand if I express some skepticism about the assertions you are making here. Maybe I missed something, but I saw nothing in the screenshots that you posted that showed anything other than the car being in developer mode, and I saw nothing that actually showed that this was a car on MCU2. We have no history of you previously providing reliable information on Teslas, such as we have with @verygreen or @wk057. Do you have anything to offer us other than making unsubstantiated claims? And your latter claim would be a bombshell if true.

 

[viper2ko]

That’s quite a blanket statement that doesn’t serve anyone well without clarification. Specifically, what do you mean by this? All cars, by any manufacturer, ‘begin to die’ at 4-5 years? Only Teslas begin to die at 4-5 years?

It’s a big difference replacing a part at 4-5 years as opposed to your entire vehicle ‘beginning to die’. What statistics & evidence do you have for this statement?

MCU will die around that time

 

[thenaimis]

So does this mean FSD owners with get a free upgrade to MCU2 then?

 

[Ken7]

He's referring to a specific problem with the flash storage on MCU1 cars wearing out due to excessive and unnecessary logging activity. When this happens the car becomes unusable until the MCU is replaced or the flash storage on the MCU is replaced. Some third parties will replace the flash chip (which is soldered on and not easily replaceable), but Tesla will only replace the whole MCU, at a cost of around US$2500 IIRC.

This problem has been well documented and reported to Tesla but they have never shown any interest in fixing it -- until recently when the problem started getting a lot of press. The fix is simple: Configure the embedded Linux OS to not log so much useless data that nobody ever accesses to the flash storage.

No, I understand that, but saying the "MCU will die at around 4-5 years" is very different than saying "All cars will die at around 4-5 years"...at least I think so. I'm not saying this should happen, it shouldn't, but with so many negative threads in this forum it's better to clarify what is specifically meant for those not familiar with what's going on.

 

[thebishop]

Unfortunately it seems that all cars will die approximately at that time - not by design, but by omission to address this trivial but real world problem. The fix being to pay 2-3000USD to replace a whole computer, when in reality it is just a hard drive (storage) failure to use computer terms - in this case a part that should/would be replaceable at a fraction of that cost, or even avoided completely by using some software engineering resources to e.g. mount a tmpfs file system that doesn’t write to the actual storage.

it seems my own icu is about to fail now, not accessible through the app for over a month (just waiting the required few months to get a service slot so someone can look at it, and hoping that the car will remain driveable until then. (I’m driving a 2015 model)

people (at least myself) are just a bit upset that the issue have been identified, but ignored by Tesla and putting extra pressure on service centers to do unnecessary replacements of mcu units, when a software update could have fixed it, or at least postponed it for a long time, perhaps until a mcu upgrade path was in place.

 

[thebishop]

So the car will not be dead, it will just require an Expensive repair to work again.

 

[Chaserr]

He's referring to a specific problem with the flash storage on MCU1 cars wearing out due to excessive and unnecessary logging activity. When this happens the car becomes unusable until the MCU is replaced or the flash storage on the MCU is replaced. Some third parties will replace the flash chip (which is soldered on and not easily replaceable), but Tesla will only replace the whole MCU, at a cost of around US$2500 IIRC.

This problem has been well documented and reported to Tesla but they have never shown any interest in fixing it -- until recently when the problem started getting a lot of press. The fix is simple: Configure the embedded Linux OS to not log so much useless data that nobody ever accesses to the flash storage.

The fix is actually simpler - hackers with rooted cars already fixed it on their vehicles by changing the logging to a TMPFS partition and nmo longer writing directly to the chip thousands of times every minute. It's all those writes that kill the chip and to anyone with any kind of linux background, it's ridiculous that hey aren't logging to tmpfs. People are floored when they learn Tesla isn't - it's such a basic assumption there's no reason they chose otherwise.

Tesla can also reduce logging of the linux file system, that would reduce the quantity of useless logs, but they should have started with logging to memory and then periodically saving to chip instead of always writing to chip directly every time.

So the car will not be dead, it will just require an Expensive repair to work again.

So the car will be dead unless is expensively repaired. All unworking "dead" cars are an expensive repair from working again. If you make this distinction, it's because you believe there is no such thing as a dead car.

If they don't fix logging, this known issue will eventually become an NHTSA recall. Rear view cameras are legally required safety equipment, making predictable and known failures of the MCU to a specific cause a safety defect as defined by the NHTSA. It's probably the only reason they are fixing the logging after all these years - recalls would force them to replace the MCU out of warranty on Tesla's dollar.

 

[scottf200]

No, I understand that, but saying the "MCU will die at around 4-5 years" is very different than saying "All cars will die at around 4-5 years"...at least I think so. I'm not saying this should happen, it shouldn't, but with so many negative threads in this forum it's better to clarify what is specifically meant for those not familiar with what's going on.

And it is not clear what has been done or planned so this 4-5 could really be 10-11 years at this point.

Elon Musk on Twitter

 

[thebishop]

Chaserr, if you read my preceding post, I think you can guess where I stand in this debacle - if not, I think it is completely fubar and Tesla is very late on the ball. Of course you are right, but I think you’d agree that there is some level of distinction here - if the repair to fix a “dead” car is five bucks, it’s no big deal - but when it is several grand (like in this case), it sucks. And if it is tens of thousands... so deadness is related to cost of repair...

 

[thenaimis]

Tesla can also reduce logging of the linux file system, that would reduce the quantity of useless logs, but they should have started with logging to memory and then periodically saving to chip instead of always writing to chip directly every time.

Linux on an embedded system is a problem that's been solved many times before, Tesla is just doing it the most bumbling way possible. I guarantee you more thought and effort and design went into OpenWRT and the like than went into the Tesla MCU. Tesla's software/firmware development approach appears to be "if it works at least one time in ten, it's good enough, ship it and move on to the next fart mode" vs "let's take the time to develop and test and get it right the first time".

 

[Chaserr]

"if it works at least one time in ten, it's good enough, ship it and move on to the next fart mode"

If MCU1's browser worked half that often it would be an improvement. I know fart mode doesn't use the browser because it does work. Tesla's priorities need adjustment.

 

[scottf200]

And it is not clear what has been done or planned so this 4-5 could really be 10-11 years at this point.

Elon Musk on Twitter

Thread:
green on Twitter

 

[thenaimis]

If MCU1's browser worked half that often it would be an improvement.

Believe me, that thought definitely crossed my mind when I made up that one time in ten number

 

[Flaminis]

@Flaminis, as you are a brand new member to these forums, and these three posts in this thread are your first and only posts on TMC, I hope you will understand if I express some skepticism about the assertions you are making here. Maybe I missed something, but I saw nothing in the screenshots that you posted that showed anything other than the car being in developer mode, and I saw nothing that actually showed that this was a car on MCU2. We have no history of you previously providing reliable information on Teslas, such as we have with @verygreen or @wk057. Do you have anything to offer us other than making unsubstantiated claims? And your latter claim would be a bombshell if true.

OK. I am a new user. So what? I have very little free time, and I visited TMC only as a reader. And just the other day I conducted an experiment to replace mcu2 with mcu1. Moreover - it all started much earlier, since MCU1 and MCU2 work the same way on my work stand assembled on the wiring harness from MS 2016. So the idea arose to try on a car. The result photo resulted. Do not believe? Try it yourself and see for yourself. I have been repairing Tesel long enough to own the issue, including in the field of update and modernization of MS and MX.

 

[_jmk]

The fix is actually simpler - hackers with rooted cars already fixed it on their vehicles by changing the logging to a TMPFS partition and nmo longer writing directly to the chip thousands of times every minute. It's all those writes that kill the chip and to anyone with any kind of linux background, it's ridiculous that hey aren't logging to tmpfs. People are floored when they learn Tesla isn't - it's such a basic assumption there's no reason they chose otherwise.

Linux kernel developer says hi. I can understand it very well why Tesla doesn’t do tmpfs - they want to have persistent logs. In a car crash a log that does not exist does not provide much value. I’m quite sure Tesla does sync logging without writeback.

 

[BPeter]

OK. I am a new user. So what? I have very little free time, and I visited TMC only as a reader. And just the other day I conducted an experiment to replace mcu2 with mcu1. Moreover - it all started much earlier, since MCU1 and MCU2 work the same way on my work stand assembled on the wiring harness from MS 2016. So the idea arose to try on a car. The result photo resulted. Do not believe? Try it yourself and see for yourself. I have been repairing Tesel long enough to own the issue, including in the field of update and modernization of MS and MX.

Can you elaborate on what you mean by the IC is interchangeable? We were under the impression that while they use the same cable between the IC and MCU, they are communicating on completely different protocols. With IC1 and MCU1 having an ethernet connection between them and IC2 and MCU2 having an eDP connection between them. IC2 being simply a display while IC1 is a full computer. Theoretically IC1 could work with MCU2, but IC2 shouldn't be possible to work with MCU1. By interchangeable do you just mean they have the same cable between, so it's easy enough to replace IC1 with IC2?

 

[markb1]

Linux kernel developer says hi. I can understand it very well why Tesla doesn’t do tmpfs - they want to have persistent logs. In a car crash a log that does not exist does not provide much value. I’m quite sure Tesla does sync logging without writeback.

My understanding is it's basically kernel messages that are being logged to the eMMC. Those could be useful during development, but probably not so much in a production vehicle. It's not the "black box" type data that being logged there (or if it is, it's not that much compared to the kernel logging).

Edit: The problem is described at about 8:45 in this video. The logs that Tesla pulls to diagnose a problem are actually on the SD card, not the eMMC. The logs written to the eMMC are essentially worthless.

 

[Flaminis]

Can you elaborate on what you mean by the IC is interchangeable? We were under the impression that while they use the same cable between the IC and MCU, they are communicating on completely different protocols. With IC1 and MCU1 having an ethernet connection between them and IC2 and MCU2 having an eDP connection between them. IC2 being simply a display while IC1 is a full computer. Theoretically IC1 could work with MCU2, but IC2 shouldn't be possible to work with MCU1. By interchangeable do you just mean they have the same cable between, so it's easy enough to replace IC1 with IC2?

IC1 and IC2 are the same in connection, but completely different in functionality. I tried at the stand to connect MCU2 to IC1 and vice versa - to no avail, it does not work. Replacement only with a pair of MCU / IC. Further, the most significant software problem, since intel is much more closed than tegra. Also, besides this, switching to MCU2 will be a little more difficult for pre-styling MCU1s until the beginning of the 15th year with 3 top-row connectors on the back of the MCU - there you will have to spend considerable time on repositioning the CAN and LIN buses. Such work was carried out when replacing the first generation of MCU1 with the second, from a machine of 15 release