Hacker News new | past | comments | ask | show | jobs | submit login
A Single Component Can Brick Older Teslas (thedrive.com)
150 points by pfortuny 7 days ago | hide | past | web | favorite | 97 comments

This issue is best explained on Rich Rebuilds' recent video here: https://youtube.com/watch?v=o-7b1waoj9Q&t=525

This has been a known issue for some time, and it's amazing Tesla hasn't fixed it yet. As explained in the video, the issue is simply the base linux OS has full syslog's still enabled, which over time burn own the eMMC chip used for storage. Currently Tesla just replaces the entire media unit when this happens, which is extremely expensive for them. In reality they only need to replace a tiny part instead of tossing entire boards.

The GOOD news is this issue is almost fully solvable through a software update. They just need to disable base syslogs, or at least only store logs in RAM while car is running (if they need those logs for debugging purposes, which I doubt). Long term, they should replace this eMMC with a proper SSD, or removable SD card that's easily serviced when it goes bad (as is the case in other parts of the car).

I think this must be an issue of visibility in the company, and the right engineer just isn't aware of this issue yet. I hope this gets more visibility and gets patched in a future software update.

"Replacing a tiny part" is trivializing the work necessary to do this, in my opinion.

eMMC flash is typically a ball-grid array part and it's soldered down hard to the motherboard of the processor. Almost every mobile device has the same setup and it's tricky and expensive to rework this chip.

You need to carefully desolder it off the board, reball the part with the correct masking stencil, then reapply it without torching the rest of the board, missing a solder connection, or zapping any other component with static electricity.

You can see a similar process done on an iPhone here: https://www.youtube.com/watch?v=y4M9uAZlbK4

You can understand why Tesla would rather replace/refurbish the board than try to field-repair it.

They have been replacing the whole media unit including the screen (and charging customers $2k-5k for the priv) where they could replace the processor module board (which is "just" a add-in board inside the media unit) keeping the rest of the media unit and lowering costs.

Sure refurbish the processor module and replace the eMMC at a proper rework station but replacing the whole media unit esp when the failed part is on a removable board just seems like a huge waste to me esp when the customer is footing the bill.

It feels like they should just turn off syslog in production builds, release it in a firmware update and offer a recall for everyone affected by broken board.

Luckily Tesla isn't very space or money limited with this pretty ciritcal component. An SD card would make life easier for everyone, as the logs could be easily read out and the booting OS changed - yay for actually owning the device you paid for. But wait: That's not something Tesla wants.

eMMC is literally the equivalent of an SD card soldered down to the PCB. It’s more mechanically stable and also way faster.

In my experience, removable SD wouldn’t hold up to an application like this.

An SD card might work fine if it is mounted properly. The slot found on a Raspberry Pi would not at all be sufficient.

If it were held in and held against some robust contact pins it likely would be fine, even under automotive conditions. There are SIM card slots that are used on heavy vehicle computers and controllers (the ones that run the engine and so on) that are robust enough to hold a SIM card in place for years of excessive daily vibration.

Whenever I drop my phone I see the "SimProcessor" service spinning up...

I suspect that designing reliable spring contacts isn't as easy as it seems...

Yeah, phones aren't designed to have robust SIM slots, they're designed to be thin, so they use very low profile SIM cradles that are not robust to impact.

The trade-offs for a high vibration environment are very different.

The actual logs Tesla seem interested in (including the stills of things they are interested in) get written to a removable SD Card before getting uploaded to the Tesla mother-ship.

You are not wrong that a soldered eMMC (compared to a eMMC held by a ZIF or a removable SD Card) would be more mechanically stable and potentially faster (A fast uhs-ii sd card compared to a cheap slower eMMC for example), just saying that Tesla already use removable SD cards in production cars today (which doesn't brick your media unit if it dies or dislodges).

Storing the OS on a removable SD Card is (imo) a bad idea, but if they are really interested in these logs they already have a easier to replace removable storage "drive" they could write the logs to instead of burning up the eMMC.

Or just add an SD card reader on the board and output the logs there if they need it so much, and keep the rest on the EMMC.

This is the right answer

Replace the board, then you can refurbish it in a specialized lab

Same reason why genius bars won't replace components, just boards

So it's not fixable with software update?

The under lying issue can not be fixed with software. the eMMC is simply running out of write cycles. BUT they can mitigate the issue by not writing the syslog to the eMMC allowing the remaining write cycles to last much longer (This change could be done with a software update).

On the newer versions of the Media Unit instead of disabling writing the syslog to the eMMC they added more storage to the processor boards which isn't going to solve the problem just push it from appearing to further down the road.

The problem is that there is significant write amplification as the used space on the partition approaches the total space of the partition.

To say that the choice to use eMMC is the fault is to say that ANY use of flash storage is a faulty decision.

If there is sufficient space on the drive to mitigate write amplification, then the media will last a very long time indeed. Longer than the drivetrain, certainly.

The problem is that Tesla doesn't delete logs it has collected from the cars. All Tesla vehicles (as I understand it) upload their logs more or less continually. Currently, the firmware on the cars doesn't delete those logs once they've been uploaded, presumably so that they're available when it is time to service the vehicle.

The disk filling up due to bad log file hygiene, coupled with the fact that the storage is flash-based, together cause the issue.

Most eMMC cards use really primitive wear levelling algorithms.

A simple firmware update to the eMMC chip could make it use a wear levelling algorithm that really does spread writes evenly over the whole chip. Current implementations simply use a sector till it goes bad and then using a spare till that goes bad, etc. After 1% or so go bad, the whole device rejects writes entirely.

With a decent implementation (like ssd's mostly do), you will never be able to kill a card in a lifetime.

Wow, this is exactly the tutorials that you get on "How to get your Rasberry Pi to run stable for extended periods of time". Exact same failure mode, exact same fix proposed.

> Currently Tesla just replaces the entire media unit when this happens, which is extremely expensive for them. In reality they only need to replace a tiny part instead of tossing entire boards.

Do you know that they toss the old media units? Are you sure they don't swap the entire media unit to simplify service procedures, and have have the old units inspected and refurbished (i.e. eMMC module replaced) for future repairs?

That sounds way more efficient than training all of the shop workers to diagnose and swap out individual parts of the media unit.

An SD card has a much different set of problems, including physical contact issues. eMMC is an acceptable tool for the job, it's just complete negligence to not use a batch logging technique if you even need full syslog data.

They use an SD card for the car logging, according to the Rich Rebuilds video, so it's doable. It just needs to not brick the car when it fails.

That they use it in other applications doesn't make it automatically the best idea. SD cards are fairly unreliable compared to the other options, and as Rich's friend points out, smartphone manufacturers use eMMC and don't have issues because they understand wear cycles.

It is a bit baffling that a company which enables “autopilot” OTA does not do this as well...

If this anonymous coward's characterization of Tesla is true and accurate, it's not surprising https://www.reddit.com/r/EnoughMuskSpam/comments/99sbwa/form...

The wording makes it sound like you're calling the parent comment an anonymous coward. I also suspect a lot of people didn't catch the Slashdot reference.

Maybe he was hit / smashed over the head with an OPEN SOURCE CD?

Wow. Thanks for that link. Some amazing inside stuff. My favorite anecdote:

most of the time me and the other firmware folks were chasing elon's whims about what to do with firmware. where i should have been fixing critical issues in the system i was pulled off to do shit like add farting unicorns

Why did your choice of words include “anonymous coward”?

On Slashdot, "anonymous coward" was the default username for anyone posting without being logged in.

The linked reddit post is from a user who claims to have worked for Tesla in the past, and is (presumably) not using their "real" reddit account to post it.

I don't read it as an insult.

> On Slashdot, "anonymous coward" was the default username for anyone posting without being logged in.

Gotcha. That makes sense. Slashdot was never my thing. Thanks for clarifying; I had read it as bafflingly unjustified aggression.

Problems with an SD card is that it will wear out even faster than an eMMC due to lack of FTL, and also friction fit instead of soldered connections means the part is susceptible to wiggling out of the socket and also corrosion between the contactors.

Not sure of the benefits of an SSD over an eMMC. Guessing the former will have a more sophisticated FTL and other things.

Multiple companies make high endurance SD cards for things like dash cams and automobiles. Take, for example, WD https://www.westerndigital.com/products/embedded-removable-f...

Didn't know that, thanks.

But there's still the problem of a friction fit connection in an environment with a lot of vibration and contaminants. Seems like these would be good for use cases where the part needs to be removable and also have high write cycles, like a dash cam or data logger that has no other interface to a PC.

Also the eMMC interface exposes quite a bit of the underlying hardware (see mmc-utils on Linux). With SD cards I think you're generally stuck with some kind of SMART interface.

> Currently Tesla just replaces the entire media unit when this happens, which is extremely expensive for them. In reality they only need to replace a tiny part instead of tossing entire boards.

Am I the only one thinking about the recycling and cost implications of doing this?

Well, if you have some thoughts on it, I am curious what the other approach would look like. What are your thoughts?

I'm thinking they would have all the labor of taking it out, and all the labor of putting it in, but then much additional labor and repair time incurred by doing the component level repair instead of just grabbing another radio off the shelf. Recycling would be possible on the unit later and it could be installed as a refurb unit in another vehicle.

This is rather disingenuous. Of course Tesla doesn't replace the eMMC; that's a soldered on chip. No car manufacturer in the world does chip level electronics repairs. Instead you replace the entire board, and I have no doubt you can get this repair from Tesla.

That's not to entirely excuse Tesla. If you have a modern operating system running from flash that needs to work for 20+ years as people expect from a car, it needs to be very carefully designed - all logging and runtime data written only to a RAM disk, system and user data on entirely separate partitions, etc.

You are right but at the same time one does not expect a component of the dashboard to actually brick a car. I guess.

While counter-intuitive, I have actually encountered this issue with other cars as well, specifically a Ford f150 where an internal problem in the APIM module (accessory protocol interface module, essentially the dash touchscreen controller) essentially bricked the truck by spamming the canbus with erroneous signals. Remember that modern automobiles are rolling networks with multiple interconnected controllers, some of which are required for the vehicle to function.

Note that this doesn't excuse Tesla here, since the situation I discussed is very rare, normally if that module fails the vehicle will still start and run. Tesla engineers should absolutely have been aware of this issue, as pointed out up thread there are multiple tutorials for ras-pi SD memory preservation, and I have trouble believing a competent EE shouldn't be aware of life issues due to eMMC. It also shouldn't brick the car, normally automotive electronics are designed very carefully to avoid single points if failure, with fallback routines and safety "limp-home" modes in case of problems.

bricked the truck by spamming the canbus with erroneous signals.

Wasn't preventing this one of the design goals/selling points of CAN?

Yes, that is one of the strong points of CANBUS. Like I said in the original post, this was a very rare failure. However, the APIM managed to spam the bus in just the right way where it de-synced modules; when I initially connected to the vehicle w/ a snap-on scan tool it was throwing codes for BCM and TCM non-comm, as well as codes that implied the ECM was seeing different speeds on the CKP & CMP (crankshaft & camshaft sensors). The CKP/CMP disagreement was what caused the vehicle to be 'bricked', since the engine management had no idea where the crankshaft & valves were in relation to each other.

Near as I could tell from my scope, the APIM was spamming the bus with exactly the right frequency to interrupt the ECM during it's scan of critical sensors. It was an extremely rare failure, and to Ford's credit they covered both the repair as well as my shop's diagnostic time.

edit: To make it clear, I have seen 2 vehicles that still operated with a direct CANBUS short to ground, as well as a vehicle that had CANBUS shorted to 12V+. In these cases, aside from expected failures (such as the BCM systems not responding, or transmission limp-home), modules were able to fall back into either safe states (limp-home, in the case of the TCM) or just a dashboard warning light (in the case of BCM no-comms).

Wow! Unbelievable. I mean, just SEPARATION.

Thanks for the anecdote!

“Bricked” is supposed to mean “permanently and unfixably ceasing to function”. That’s absolutely not what is happening here. The article is completely and inexcusably wrong on this point.

The car won’t run when the eMMC chip fails, and Tesla solution is a new MCU board which costs $2,700 out of warranty. Not surprisingly Tesla is not desoldering and reworking just the eMMC chip.

There are any number of components that can disable a car, from the battery to the starter to something with the ignition, electronics, anti-theft, etc.

Sometimes the repair is as simple as a new battery, sometimes the repair is an expensive piece of hardware.

Yet those things are crucial to the fundamental operation of the vehicle. We're talking about logs no user cares about here. It's just sloppy and a silly failure mode.

Anti-theft is not crucial to the operation of the vehicle, and that had certainly immobilized plenty of vehicles, sometimes in expensive to fix manors.

Now if the article was that Tesla Model S has a chip which wears out and the board holding the chip is expensive to replace, and maybe even getting into why don’t they push a software update to lower the writes to that chip — I would not disagree.

The article falsely claimed the cars are “bricked”. As it’s the main thrust of the article, it should be retracted.

> However, until the company starts stocking parts like the eMMC chip, as well as release detailed service manuals to the public, Tesla is going to be looking at a number of newish cars dead in a junkyard real soon.

They should stock a chip which is soldered to the board, and what, do reworks? That’s asinine.

Newish cars dead in a junkyard? Totally false. It’s an expensive repair for a problem that could have been avoided, and hopefully Tesla will remedy with a firmware update.

I'm not sure you understand the situation.

This is the board the chip is on, which Tesla does not offer to replace: https://share.icloud.com/photos/0u78AylGb9fv8QHQnyr9IC3nA

This is what Tesla will offer to replace: https://share.icloud.com/photos/0MVG8edJheaHYiEp7yWKkVePg

Is that what you were imagining?

According to the video, the log is not used for anything and is basically unnecessary for the most part.

Why a full memory chip logging data which is never used should brick a car is simply price gouging.

There is no need for it whatsoever.

Thousands of dollars to replace a board because of a full memory chip? That is even worse than Apples repair racket, at least in Apple's case some other circuitry besides memory is faulty - https://www.youtube.com/watch?v=2yJKix17yYE

Erm, not full exactly. This is more like a rechargable battery that cannot handle being charged anymore. The old battery is not "empty", it's dead. This chip is not "full", it is dead. The lifetime physical endurance limits are exceeded, and functionality is lost.

Except Apple batteries die because of physics, Tesla has this issue because Tesla decided to:

1. Log something they never read back

2. Use a soldered down chip (they use a SD card in other locations)

3. Crash the media controls when the unused logs cannot be written

4. Disable certain car features, potentially immobilizing the vehicle because the media center is off.

There are several ways that Tesla could have prevented this issue, and the fact that they've never bothered to resolve the issue in later iterations is just baffling.

I read your argument, but I do not understand what you are taking exception to.

Smart phone batteries degrading is inevitable, these issues with Tesla’s cars aren’t, therefore it’s a bad comparison.

> all logging and runtime data written only to a RAM disk, system and user data on entirely separate partitions, etc.

I suspect "we can fix it in a software update" lowers the priority of actually shipping this design.

and then add in "autopilot this year" and "model y coming soon", you get indefinite postponement.

As is so often the case with articles about Tesla the headline is completely misleading. No cars are getting bricked. Tesla fixes that problem by replacing the bad board but they won't replace the bad chip on the board and they won't sell the chip separately. Other manufacturers don't generally do that either.

Except this is exacerbated by a very dumb software oversight that is corrected for by virtually everyone in the Tesla software modding community, and in many cases Tesla has not covered the board replacement after the initial warranty expires (which happens just before the estimated failure time).

And as always anyone defending them is flagged like you despite this being pretty clear

> they won't replace the bad chip on the board

There is no bad chip on the board.

A full chip is not a bad chip, and there is no reason why the board should stop working on account of a full memory chip which contains a syslog that is not used for anything.

Hacker News is riddled with shills and apologists for atrocious corporate behaviour.

You misunderstand both the functional properties of flash storage and telsa's blunder. Tesla's mistake was sending too much data to the chip, yes, but it exceeded the WRITE ENDURANCE, not the capacity. https://en.wikipedia.org/wiki/Flash_memory#Memory_wear

(Incidentally, not a shill or shareholder, but rooting for tesla due the fact GM pushed for leaded gasoline and ford would rather litigate than fix dangerous vehicles. We're rooting for the underdog here hoping for global positive change.)

Apparently the issue is the eMMC storage wearing out and failing, not simply getting full. Since it’s soldered on it is not a feasible repair at the shop.

The orphan car problem is a serious issue with non-Teslas, too, but I will personally stick to repairable vehicles. You know what you'll never, ever have trouble finding parts for? A Mustang or an F150. Corvettes. Carollas. All of the ubiquitous cars will have parts produced for a seriously long time.

XJ cherokees here. Love em. Room for elbows whereever you need to wrench, and highly reliable heavy parts. The electronics are meh, and rubber degrades with time, but you can replace all that stuff with a simple screwdriver.

The corner auto parts shop stocked almost every part I needed to work on a 1982 F-150.

Isn't this more of a network effect than something inherent to Teslas?

Nope, tesla will not allow you to order parts, or even look at a service manual as a mere owner. Its crazy that people on HN of all places defend their customer-antagonistic practices.

Any other examples of the big 3 US, German, or Japanese car makers having a similar issue? Where a media center issue causes the car to not run and the manufacturer refuses to fix the issue or even provide a part for it?

The article is misleading. The manufacturer does fix this. They just don't fix the bad chip. The replace the card instead.

Except they don't if the car is out of warranty, which (at least in Canada) is 4 years or 80,000 km.

I don't think this is just me but I believe cars should be able to last longer than 4 years and not get bricked by fault of the manufacturer and then not at least easily give me the ability to fix it myself if they won't.

Do they not replace it out of warranty or simply don't pay for it out of warranty? There is a huge difference between those two options. If it is the former, I would imagine it is just a matter of time before a lawsuit. If it is the latter, then isn't this functionally the same as a particular model of car having a bad transmission or similarly critical ICE component that regularly fails much earlier than expected?

Powertrain components are required by EPA to have a 10yr/100k miles warranty, I thought? So it's not exactly the same situation because fundamental parts of the powertrain are covered by a longer warranty.

That doesn't appear to be true [1]. It seems like a majority of powertrain warranties are in the 4-6 year and 50k-70k mile range. Tesla's 4 year and 50k warranty on this part would therefore be on the low end, but it matches the powertrain warranties for Audi, BMW, Volvo, Mercedes, and several other manufacturers.

[1] - https://www.motor1.com/features/253277/comparing-new-vehicle...

According to [1], Tesla will not replace the minimum removable unit, but only the entire assembly, at a cost of around $2.7k. And, as with other parts replacement issues at Tesla, it is apparently not a quick turnaround.

The article is wrong to say these cars are bricked, but it is not a small issue, either.

[1] https://youtube.com/watch?v=o-7b1waoj9Q&t=525

Wait. Do they have a fix but the fix is replacing the board and not the bad chip?

Is Telsa not fixing things or did they just use something that had a short life span? Not sure why I read this article.

Tesla screwed up by using eMMC memory (flash memory with an integrated controller) and not disabling system logging. The additional writes cause the flash memory to wear rapidly, which should have been mitigated as this is not a new issue in embedded devices. As the chip is soldered and not socketed, the solution is to swap the entire (expensive) board, and Tesla won't do this for out-of-warranty vehicles and hasn't extended warranty support.

What makes this somewhat egregious is the lack of foresight, as well as the fact that Tesla uses standard socketed SD cards in other modules in the vehicle.

Tesla won’t do this for free for out-of-warranty vehicles.

Replacement cost of the entire board is unfortunately high at around $2,700.

[1] - https://teslamotorsclub.com/tmc/threads/2700-to-fix-mcu-migh...

Ok but why not fix the engineering flaw so so it isn't a $2,700 fix? This seems like doing a software fix, where you add buffering to your logging writes, would go a long way to fixing this.

From your link:

>I think we are on drivetrain #5 and it is now that one clunking intermittently, so maybe we take that one back in. We are on battery charger #2 and battery rebuild #3. We had most of the upgrades (wind noise on the door windows, etc). We had a left rear door handle start to go bad, took it to the shop and they fiddled with it and wanted to replace it, but afterwards no problems so we did not replace it.

Drivetrain #5, charger #2, and battery #3. All under 125k miles. Wow I’m not so sure I’ll be buying a Tesla for my wife.

Yes, that is one anecdotal data point on a 2013 Model S. The 2012/2013 Model S drivetrain was notorious. Tesla warranted them for 8 years, and replaced them when they started to make noise. Here's an article with real statistical analysis saying 2/3rd were replaced by 60,000 miles. [1] This is back when Model S was basically a prototype.

Time will tell with the Model 3 how reliable it is. A major selling point is the reduced complexity of an EV. The Tesla drivetrain and battery is now widely considered the world's best and most reliable. Tesla has claimed the Model 3 drivetrain can be re-used on the semi and that it's tested to 1,000,000 miles [2]. Take that with a grain of salt, but it's a world different from a 2013 Model S.

[1] - https://www.greencarreports.com/news/1101153_two-thirds-of-e...

[2] - https://cleantechnica.com/2018/10/16/tesla-model-3-motor-gea...

Perfect. Thank you.

Thank you. What a willful ridiculous article from the author.

No, it isn't. When the board is out of warranty they make you replace the entire media unit, which can cost up to $5000.


The late 90's security systems electronics for Mercedes were pretty temperamental. Bricking the car is what it was designed to do. I know firsthand that it's capable of bricking the car for the wrong reason.

EDIT: Also, I don't know how it was for dealers, but 3rd party repair shops just throw their hands up for those systems.

This affects pre-facelift MCU1 car, which is before about April 2016. So I suppose a solution now is to upgrade the MCU to MCU2. Elon says that will be possible.


Model 3 owner here. Having same issue as back in March. No AP, no FSD and most frustratingly, no cruise control. Multiple TS steps over phone with no resolution. The earliest appointment was months out so I drove into a service center. A frazzled, yet personable, tech assured me that the issue was NOT from the recent FW update but rather a hardware malfunction with the left repeater. I pressed for details- is it wiring, hardware, physical damage? He couldn’t tell me, but insisted that it had nothing to do with the previous FW update and that another FW update wouldn’t resolve it

Tech scheduled a service appointment for 4-13, much better than I could find in the app. On 4-4 Tesla pushed a FW update, which I guess is pretty common before a service appointment. On 4-5, a Tesla rep reached out and said the issue WAS in fact, with the original FW update and that the more recent FW update had resolved:

“Hello Sam,

We have reviewed your vehicle logs and alerts. At this time we do not see any issues with the Autopilot system as well as you confirming that the system is operating as designed. Since this is the case there will be no need for you to come in for your scheduled appointment. While there is no way to say that you will never have an issue again, at this time there is no issue that needs correction. If you do have an issue in the future you are always welcome to create another appointment with your concerns.”

I responded:

“Ok- I’d still like to understand what happened. It is generally acceptable that the universe is getting more disorderly. It is perfectly acceptable that something goes wrong and we don’t know why. It’s significantly less understandable, that the issue mysteriously resolves it self. Does that make sense?”

Tesla Response:

“Hi Sam,

It was found to be a software bug in the last update that was performed causing your cruise control not to function. That was resolved in the last update you performed.”

The rep then canceled the 4-13 appointment without further explanation or communication.

The issue returned yesterday (5-13) and now the earliest appointment is mid June.

Cruise control existed in 1958. I get that Tesla has “tight integration” but the lack of a fall back/degraded performance mode seems ridiculous. This is before considering the lack of NoAP and FSD, which adds insult to injury- Those features represented nearly 15% of the vehicle cost in my case ($8,000 upfront).

Convenience in LA traffic was a primary consideration when purchasing the Tesla. The lack access to purchased features is irritating, but I knew they were bleeding edge. The further loss of a ubiquitous feature like cruise control is even more irritating. Tesla’s handling of the situation feels ridiculous.

I think the basic pattern of how customer service is handled, along with Tesla's selling points, can explain this.

Call centers and customer service departments in general report statistics that are used to measure their performance. Individual employees are instructed to "resolve" tickets and to make sure that no single ticket take more than a certain amount of time to be resolved. This creates an incentive to look at the tickets in a first-in first-out order and find a way to close them. An explanation was selected from a list because that explanation has gone unchallenged when addressing similar tickets. The appointment was cancelled and the ticket was recorded as having been resolved by customer service and software. This is a win for Tesla's internal reporting on the number of tickets that require a technician to physically interact with the vehicle. They can brag about most issues being resolved by software because they're a cutting edge company and are above crude hardware fixes like those other boring car companies. If you show up in person for repairs that means, in their view, that customer service has failed.

In short, this isn't Tesla being exceptionally bad or exceptional at all. It is an example of Tesla doing the same old thing that all the other companies have been doing.

My worst car ownership experience was yelling at the people at JiffyLube for replacing filters that were in perfectly good condition and trying to charge me for it even though I only asked for an oil change (they then made a big show of shoving them back in as violently as possible). As awful as mechanics tend to be, a component being too easy to repair or replace by anyone who can read a manual is better than begging a single entity for repairs.

This report is both impressive and frustrating. I’m sorry your AP is not functioning and their fix was not permanent, that must be incredibly frustrating as a huge benefit of the car is the AP system.

At the same time, it is pretty amazing they are remotely logging into your car to review system logs and diagnose the issue, and then pushing firmware updates to try to remedy the problem.

There may be no choice but to drive back to the service center to try to get a quicker response from Tesla. At some point if they can’t fix it there could be a remedy under the lemon law — they only get 3 chances and a certain number of days AFAIK.

I can understand how a single fault could disable the adaptive cruise and likewise all of AutoPilot functionality. But Tesla is expected to be able to fix the issue promptly.

> At the same time, it is pretty amazing they are remotely logging into your car to review system logs and diagnose the issue, and then pushing firmware updates to try to remedy the problem.

It really isn't if it didn't fix the problem and they used it as an excuse to not follow up with their scheduled appointment.

This would be like if I was fixing a bug, SSH'd into a live instance, didn't fix anything, then filed the ticket as "fixed" and refused to follow up on it. That's not amazing, that's pretty sketchy.

Reminds me of of one my first projects. It was a basic contact entry form for a Dog Rescue. It was a PHP form dumping to FileMaker. I had updated been testing the form and forgot to update the FileMaker connection strings back to the prod DB.

My boss called me around 9pm saying WTF. I started stalling, put him on speaker, then remoted in and fixed the strings (this was on my Samsung Blackjack running Windows 5- I think). I told him to check again because it was working for me. He gave an incredulous “huh” and said see you tomorrow. I thought I’d gotten away with it. He called me in first thing the next day- told me straight up: I get that things break, they don’t tend to fix themselves. He gave me a chance to own up, and I didn’t. I was young, and dumb. Said I don’t know what happened. Couple years later I realized he knew. I’ve since learned that it’s almost always better to own up. Even if you’re never caught, most people will respect the honesty. Those that don’t probably have their own issues.

But that's not what happened.

nemosaltat didn't provide a complete chronology, but did say they had a service appointment on 4-13, received a FW update on 4/4, and a rep contacted them on 4/5 saying they reviewed the logs and the new FW fixed the issue.

Then nemosaltat responded to Tesla;

> Ok- I’d still like to understand what happened....It’s significantly less understandable, that the issue mysteriously resolves it self...

Tesla responded,

> It was found to be a software bug in the last update that was performed causing your cruise control not to function. That was resolved in the last update you performed.


> The issue returned yesterday (5-13) and now the earliest appointment is mid June.

So the issue was fixed, and then it returned. It's unfortunate but hardly sketchy.

I think gatherhunter hit it dead on. It’s metrics thing and they wanted to close tickets. I sincerely doubt the FW update they pushed had anything to do with the issue being resolved. It is common practice (according to Tesla forums) to push FW before a service appointment just to be sure the car has the latest version before it goes in.

The sketchy part for me is the inconsistency between the Service Tech and the rep who canceled the appointment. The tech (HW flaw) was very convincing, and the rep (SW flaw) was very vague. The functionality did not return immediately after the FW update, and I think the timing may have been coincidental. It’s even more frustrating that they weren’t/aren’t the least bit apologetic or accommodating. I can’t seem to get a straight answer on why basic cruise can’t be restored via a FW patch while I wait for my appointment. Is the same hardware/software required for Cruise on Model 3s without NoAP and FSD?

Presumably they know more about the root cause through looking at the logs. It would be so great if they could be more transparent about it.

On the surface it doesn’t make sense that a FW issue would be causing an issue with your TM3. What about the other ~200,000 cars on the road?

But to answer your last question, yes, it’s layers of incremental software functionality on the same hardware stack. Without knowing at which point it’s failing it’s hard to say if cruise could be enabled without AP.

As a point of comparison, I had my TM3 wrapped in protective film. As part of that process they removed trim including the side cameras to lay the film flat with fewer cuts. The shop (not Tesla affiliated) left the side cameras disconnected. Upon starting the car it reported an issue with side cameras. AP worked but degraded — wouldn’t change lanes, and cruise still worked fine. Some some hardware faults do not fully disable the feature.

>left the cameras disconnected... AP worked but degraded

That’s very interesting, and closer to what I would expect.

The newest development, when I drove in this morning, the Service Tech said it’s a seatbelt sensor malfunction.

There is a “driver seat buckled” interlock for cruise control, but the alert for that explains the reason. I’m just getting “cruise not available” with no explanation.

Yeah I unbuckled once while AP was active to try to take off my coat and the car lost its shit on me. Red flashing alarms like, “WTF you doing?!”

I think that service tech was grasping at straws, unless he actually examined the logs and saw it written there. If it was the seat belt, wouldn’t you see it indicated on the display that the seat belt was unbuckled? It displays the unbuckled indicator for all seats that have occupants detected (weight sensor).

Presumably the logs will contain the exact reason it fails? Next time they text you maybe ask if they can tell you exactly what the log file says when AP engagement fails.

I don't think you have the issue mentioned in the article.

If they could pull your logs, your emmc did not fail.

(not that they are handling other issues well)

Oh I definitely don’t. Just more of a commentary on Tesla’s “right integration” and customer service.

I'm sure the Model 3 having a single multifunction screen that does everything (combining entertainment with critical driving features) will go great.

Actually, every control in the model 3 is used for multiple functions (for example drive selector also controls autopilot, scroll wheel controls many functions, etc)

I guess you'll just have to drive with your phone.

The first half of the video is pretty cool, they're converting a Sprinter van into a "Model 3"

Rich Rebuilds zonks Tesla, again - https://www.youtube.com/watch?v=o-7b1waoj9Q

Bummer. The value of a used Model S (they are becoming attractive) has just dropped a few notches in my eyes.

I have a 2013 model S with 55k miles. Hoping not to encounter this.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact