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

2014 85 HV Battery BMS_u029 error 1 month out of warranty and after a recent OTA update, Who else?

This site may earn commission on affiliate links.
I just got the dreaded BMS_u029, the SC said new HV battery is required to fix this. Just wondering how many others have failed right after warranty ended and after a recent software update?

Couple of questions after reading several threads...

1. Has reprogramming the BMS ever fixed the BMS_u029 error?
2. How many others have failed after an update? I'm thinking of hiring a lawyer.
3. Anybody have gotten a goodwill since the warranty just ran out?
 
You realize the update 'detected' the issue with your battery, and not breaking your battery, right?
It's not even that really. It's mainly that the BMS only really ever resets after an update, and updates on the older cars have been pretty infrequent. A lot of counters and tests are reset when the BMS reboots. MCU1 finally got a little update love, so a lot of people are installing things and the BMS starts over on some checks. Some take hours, some days, some weeks or months to run.

Long story short, it's not anything new in the update itself that's new at detecting these things, it's that the BMS was nudged by the reboot to recheck things it doesn't check continuously and accelerated the detection and display of an error. The issue was almost certainly there before the update, and logs will usually confirm this if examined in detail.

Now, this doesn't help you with Tesla, since the most they're going to do, if you're lucky, is look for alerts before the warranty expired... which wouldn't be there since the long running tests (many months long rolling averages in a lot of cases) likely wouldn't have reached a trip point for some time and no alerts would be present in the logs.

TL;DR - This isn't really anything shady, just crappy luck. :confused: Trust me, if it were something shady I'd be the first to call them out on it as I have with many issues in the past.
 
It's not even that really. It's mainly that the BMS only really ever resets after an update, and updates on the older cars have been pretty infrequent. A lot of counters and tests are reset when the BMS reboots. MCU1 finally got a little update love, so a lot of people are installing things and the BMS starts over on some checks. Some take hours, some days, some weeks or months to run.

Long story short, it's not anything new in the update itself that's new at detecting these things, it's that the BMS was nudged by the reboot to recheck things it doesn't check continuously and accelerated the detection and display of an error. The issue was almost certainly there before the update, and logs will usually confirm this if examined in detail.

Now, this doesn't help you with Tesla, since the most they're going to do, if you're lucky, is look for alerts before the warranty expired... which wouldn't be there since the long running tests (many months long rolling averages in a lot of cases) likely wouldn't have reached a trip point for some time and no alerts would be present in the logs.

TL;DR - This isn't really anything shady, just crappy luck. :confused: Trust me, if it were something shady I'd be the first to call them out on it as I have with many issues in the past.

If only the new wave of tinfoil hatters like @ddb1001 looking to drum up support for a BS lawsuit would read your posts…
 
Yes, it would be great that they have logs of the error 1 month before my warranty ended then they will goodwill it but of course not right??? Either way, I agree, chalk it up to bad luck cuz it is indeed. Point of this is to see if others are starting to get the same errors. Seems like 2013's had their wave, now my 2014, then 2015's right when everybody is just out of warranty.
 
The amount of cars running into major issues should taper off as the build date reaches about Q2'14. Beyond that the vast majority of battery design improvements had been completed. 2012 and 2013 folks are pretty universally at risk of about 6 different types of pack failures. Q2'14 and beyond only really a couple of less common ones. (And, for completeness, super solid beyond Q2'15.)
 
The amount of cars running into major issues should taper off as the build date reaches about Q2'14. Beyond that the vast majority of battery design improvements had been completed. 2012 and 2013 folks are pretty universally at risk of about 6 different types of pack failures. Q2'14 and beyond only really a couple of less common ones. (And, for completeness, super solid beyond Q2'15.)
Appreciate your insight, thanks. I'm in same boat as OP and am waiting for $15k reman HV battery at my local Service Center. In your opinion, do you think the replacement reman HV packs from Tesla will have the "design improvements" you mentioned? Or will they be legacy packs that will have same problem down the road?

My story - purchased used 2012 P85 with 117k miles last Oct 13, 2022 from 1 owner in San Diego for. Drove great from San Diego to my home in Reno/Lake Tahoe. Then on Oct 16, 2022...when previous owner and myself transferred ownership vis Tesla App after I got home, received BMS-u029 error message. Trip to Service Center last week indicated "BMS reported short to HV battery which limits max charge to 50% and requires new HV battery." So, I'm in the 1-2 month queue for a $13.5k 85 kWh reman HV battery + $390 labor + $1k ish tax.
 
Appreciate your insight, thanks. I'm in same boat as OP and am waiting for $15k reman HV battery at my local Service Center. In your opinion, do you think the replacement reman HV packs from Tesla will have the "design improvements" you mentioned? Or will they be legacy packs that will have same problem down the road?

My story - purchased used 2012 P85 with 117k miles last Oct 13, 2022 from 1 owner in San Diego for. Drove great from San Diego to my home in Reno/Lake Tahoe. Then on Oct 16, 2022...when previous owner and myself transferred ownership vis Tesla App after I got home, received BMS-u029 error message. Trip to Service Center last week indicated "BMS reported short to HV battery which limits max charge to 50% and requires new HV battery." So, I'm in the 1-2 month queue for a $13.5k 85 kWh reman HV battery + $390 labor + $1k ish tax.

one advantage of being able to ship out of Texas is that there is no sales tax on out-of-state sales, basically offsetting any shipping cost. :D👍
 
Last edited:
  • Like
Reactions: NV Ray
It's not even that really. It's mainly that the BMS only really ever resets after an update, and updates on the older cars have been pretty infrequent. A lot of counters and tests are reset when the BMS reboots. MCU1 finally got a little update love, so a lot of people are installing things and the BMS starts over on some checks. Some take hours, some days, some weeks or months to run.

Long story short, it's not anything new in the update itself that's new at detecting these things, it's that the BMS was nudged by the reboot to recheck things it doesn't check continuously and accelerated the detection and display of an error. The issue was almost certainly there before the update, and logs will usually confirm this if examined in detail.

Now, this doesn't help you with Tesla, since the most they're going to do, if you're lucky, is look for alerts before the warranty expired... which wouldn't be there since the long running tests (many months long rolling averages in a lot of cases) likely wouldn't have reached a trip point for some time and no alerts would be present in the logs.

TL;DR - This isn't really anything shady, just crappy luck. :confused: Trust me, if it were something shady I'd be the first to call them out on it as I have with many issues in the past.
@wk057 is there a way to pre-emptively force a BMS reboot so it does the tests or does a reset only happen with a new software push.
 
Today I received BMS_u029 right after a SC replaced brakes and replaced my eMMC after noticing the screen was flickering (SC covered this under Goodwill due to the recall)

One thing peculiar is my previous FW version was well out of date prior to the eMMC swap, and after the eMMC replacement the SC updated it to the latest version.
 
Pulling BMS fuse will do this.

That actually doesn't force it to reevaluate its internal data, though. The reboot after an update can be different, since when the firmware changes it can bump the version of the structure for the internal data, and it revalidates the data in EEPROM while bringing it to the latest structure version, etc. It's a safe setup from a programming perspective. From a user perspective, it can be a long time between reevaluations of some of that data normally, which can give the illusion of an update "causing" an error compared to the BMS landing there normally (which it would have).
 
  • Informative
Reactions: MP3Mike and Rocky_H
Today I received BMS_u029 right after a SC replaced brakes and replaced my eMMC after noticing the screen was flickering (SC covered this under Goodwill due to the recall)

One thing peculiar is my previous FW version was well out of date prior to the eMMC swap, and after the eMMC replacement the SC updated it to the latest version.
I also got the BMS_u029 error last Oct after purchasing from private party. Got HV battery replacement for around $15k. I set up Facebook group on the issue. Tesla BMS029 | Facebook

Let us know what happens to you.
 
I also got the BMS_u029 error last Oct after purchasing from private party. Got HV battery replacement for around $15k. I set up Facebook group on the issue. Tesla BMS029 | Facebook

Let us know what happens to you.
Thanks, I've listed my car for sale as I unfortunately cannot afford a pack replacement right now. Some of the buyers have mentioned that with every update the BMS is becoming more picky about SoC and voltage imbalance on the cells. This is having the effect of raising the standards of how balanced cells can be higher and higher which is ultimately going to push older packs out of usage.
 
  • Like
Reactions: NV Ray
a quick, but important clarification

BMS_029 is not triggered by a cell imbalance, but rather a pathological reduction in brick capacity - for example, a battery pack might have 2-3 bricks with a max capacity in the 213 Ah range and 3-4 bricks with a min capacity in the 210 Ah range, with an average of all bricks in the pack in the 211-212 range. Everything is chugging along fine, then at some point one of the cells fails (usually, but not always, in one of the lower capacity bricks), dropping the capacity of the failing brick to around 206-208 Ah and eventually triggering a BMS_u029 weak short error. (note: the BMS_u029 isn’t triggered by a specific capacity delta per se, but rather an abnormal/unexpected decline in a brick’s capacity that may be the result of something more concerning… such as dendrite growth, etc.)

on the otherhand, a BMS_u018 is triggered by a SoC imbalance - typically a delta of 10-15% or more <digs up notes on SoC spec> - where no one brick has necessarily failed, but the pack overall is out of balance. interestingly, it’s possible for a BMS_u029 to ultimately result in a BMS_u018 as the capacity in the failed brick continues to degrade to the point that an overall imbalance error (BMS_u018) is eventually triggered, but the two are a distinctly different failure modes.

it’s important to be clear here that these BMS_u029 errors aren’t the result of some random OTA update, but the result of an underlying brick failure.

as @wk057 and @Recell have pointed out here and elsewhere, the fact that these errors might arise sometime after an OTA update is otherwise complete happenstance - a brick failure has occurred, and has likely been headed that direction for some time. the data (vs. anecdotes) do not support the hypothesis that OTA updates are the source/root cause of these issues.

doubtless, @wk057 can add additional color to the above 👍

(additional note: detection of brick failures by the BMS has of course improved over time, by way of OTA updates, but better detection and handling of these brick failures and improved safety is a good thing, right?)
 
Last edited:
That actually doesn't force it to reevaluate its internal data, though. The reboot after an update can be different, since when the firmware changes it can bump the version of the structure for the internal data, and it revalidates the data in EEPROM while bringing it to the latest structure version, etc. It's a safe setup from a programming perspective. From a user perspective, it can be a long time between reevaluations of some of that data normally, which can give the illusion of an update "causing" an error compared to the BMS landing there normally (which i

a quick, but important clarification

BMS_029 is not triggered by a cell imbalance, but rather a pathological reduction in brick capacity - for example, a battery pack might have 2-3 bricks with a max capacity in the 213 Ah range and 3-4 bricks with a min capacity in the 210 Ah range, with an average of all bricks in the pack in the 211-212 range. Everything is chugging along fine, then at some point one of the cells fails (usually, but not always, in one of the lower capacity bricks), dropping the capacity of the failing brick to around 206-208 Ah and eventually triggering a BMS_u029 weak short error. (note: the BMS_u29 isn’t triggered by a specific capacity delta per se, but rather an abnormal/unexpected decline in a brick’s capacity that may be the result of something more concerning… such as dendrite growth, etc.)

on the otherhand, a BMS_u018 is triggered by a SoC imbalance - typically a delta of 10-15% or more <digs up notes on SoC spec> - where no one brick has necessarily failed, but the pack overall is out of balance. interestingly, it’s possible for a BMS_u029 to ultimately result in a BMS_u018 as the capacity in the failed brick continues to degrade to the point that an overall imbalance error (BMS_u018) is eventually triggered, but the two are a distinctly different failure modes.

it’s important to be clear here that these BMS_u029 errors aren’t the result of some random OTA update, but the result of an underlying brick failure.

as @wk057 and @Recell have pointed out here and elsewhere, the fact that these errors might arise sometime after an OTA is otherwise complete happenstance - a brick failure has occurred, and has likely been headed that direction for some time. the data (vs. anecdotes) do not support the hypothesis that OTA updates are the source/root cause of these issues.

doubtless, @wk057 can add additional color to the above 👍

(additional note: detection of brick failures by the BMS has of course improved over time, by way of OTA updates, but better detection and handling of these brick failures and improved safety is a good thing, right?)
As always, valuable info. Thanks.

Terminology question - what's a brick? I've heard of individual batteries (over 7000), modules (14-16)...