My 4xe died in my driveway on Saturday after the update. Let me explain, from the perspective of a 4xe owner, how bad the response has been from Jeep/Stellantis:
- As of Monday 8am ET, zero legitimate communication from any Jeep-related accounts on any social media platform, or any other form of acknowledgement from the company (unless I've missed something?)
- I only found out about the issue after finally searching a few Jeep groups on Facebook (of all places) to see if anyone else was experiencing the weird failure mode I was after the update.
- The only remotely-official info was from a 'JeepCares' account (which is ran by Jeep) on some random off-roading forum? We were seriously all living off of screenshots from this forum, and the advice coming from the JeepCares accounts was contradictory: they claimed that the Uconnect update was separate from the telematics update, and that there was no way to stop the telematics update if the vehicle received it. Later they gave advice to defer the Uconnect update, making it sound like they were coupled.
- Due to the lack of info from Jeep, people were coming up with all kinds of "if you reboot Uconnect while the Jeep's in ACC mode, it clears the check engine light". This probably did clear the CEL but didn't fix the fault.
- There is no way to tell if you received the bad update.
- There is no way to tell if you received the 'fix' either.
- Dealerships have literally no idea what is going on.
- You're basically at risk of your Jeep going limp (power loss, unable to safely make it to the shoulder) and being stranded on the highway, even as I write this.
> - You're basically at risk of your Jeep going limp (power loss, unable to safely make it to the shoulder) and being stranded on the highway, even as I write this.
This seems extraordinary.
I was going to ask: Are you really saying they kill the vehicle's power system, effictively the engine, while the vehicle is being driven on the highway?
But no need to ask, the article says yes, that's what is reported:
> Instead, the failure appears to occur while driving—a far more serious problem. For some, this happened close to home and at low speed, but others claim to have experienced a powertrain failure at highway speeds.
Ya, that is shockingly scary. It makes me think we need some new standards about software updates to vehicles in general (or perhaps these already exist but were missed for some reason?). I can totally imagine that software used to be this ancillary selling point that didn't need such tight regulation, but as it becomes core infrastructure for the vehicle this is less of an IoT toy, and deserves stricter standards.
>> - You're basically at risk of your Jeep going limp
This has happened to me twice with a Nissan Leaf. I paid money to get a read out from the computer system, and there were no timestamps on the screens of data.
Modern cars "computers on wheels" are dreadful.
Is it possible to disconnect the power from the radios used for "over the air" nonsense? Then at least they would be stable.
From a GPS software update... [1] "This is a telematics box module update" Telematics is primarily GPS and on-board diagnostics for location, speed, and fuel usage.
A GPS update kills your entire powertrain. Appears to also engage parking for some users, super dangerous. Catbones, "Almost died on the thruway today ... with an 18-wheeler behind me. ... Jeep died, locked its hand brake and jolted so hard my face almost ended up in the steering wheel at 70mph." [1]
It is completely insane that this is happening. I did DD on a company in the automotive space a couple of years ago and flagged that they did not check if the vehicle was stationary, motor disabled before updating. They were all surprised at how I thought that this could possibly ever lead to issues.
I have Java code running on commercial aircraft. You can’t actually run Java code on commercial aircraft because the FAA doesn’t (or at least not at the time) know how to certify it.
The entire box it’s on isn’t powered while the plane is in motion (“wheels on ground”). It’s shut off before preflight and doesn’t turn back on until the plane is on the ground. The service my code is part of is responsible for queuing updates and downlinking telemetry. Updates are manual and obviously you can’t run them while in motion if the box they are on doesn’t even have power.
Cars probably don’t have to go this far, but there’s a continuum and they’re clearly in the wrong part.
Given the state of the software industry, it's honestly more surprising that this doesn't happen more often. Our industry is a complete joke, and somehow we've been given responsibility over people's lives.
According to the article, that's not what is happening. The update itself completes fine; it's the updated firmware that is buggy, and seems to cause/require a reset of the ECU while in operation. Not that that makes it any less insane, but the update process does not seem to be implicated here.
they did not check if the vehicle was stationary, motor disabled before updating. They were all surprised at how I thought that this could possibly ever lead to issues.
My anecdata is that my car won't update its software without the owner explicitly requesting it. And then, it will only do it if the car has something like 50% charge, hasn't been used for an hour, and nobody is inside.
I once tried to do the update while I was inside, and it refused.
If a software update can affect the basic functionality of the car to such a degree then the whole car should be recertified after every update, change my mind.
I really want a 4XE Wrangler to replace my aging JK at some point, on paper its amazing, lots of torque and power, decent economy for a brick with large tires, and can actually run a pure electric enough to get around town, plus still takes all the standard Wrangler parts.
However in classic Jeep style they just can't get reliability down, and the PHEV part seems too complicated for them.
If it was just reliable it would still be the best selling PHEV in America, they let that go.
There is no sign of the 2026 Wrangler 4XE it might be canceled like the Gladiator version...
My Wife just got one last year, the electric engine will give you about 17 miles on a full charge that takes about 7 hrs, its pretty much useless on full electric mode, pretty good with the milage on hybrid which is what this really is. And yes do not expect reliability, first day out of the dealership we got a check engine light, apparently one of the workers at the dealership forgot to attach a wire or hose, at least thats the explanation that we got, i told my wife to insist on getting it documented somehow or get a log from the dealer but of course they played it off as human error (total BS). Few months later and her screen started to turn off and on, or just die completely when air play was connected. Stay away from these cars.
It's probably canceled, not only for reliability reasons. EVs and plugin hybrids are probably doomed, at least in the US: The EV tax credit subsidy is gone, fuel economy requirements will be or already have been eliminated, electricity prices climbing (my rate increased almost 50% on my most recent bill) and the Trump administration is extremely hostile towards anything related to renewable energy.
This sounds like the sort of thing that happens when a team has a deliverable that slips multiple times but everyone had vacations planned for a responsible amount of time after the deadline.
Under time pressure and confirmation bias they signed off on code that was giving off signs of being broken, pushed it, and now key staff are either on airplanes, out of coverage on their phones, or cannot work entirely from memory and don’t have their computers with them because vacation.
I bet they already have communications ready, but everyone Director and above needs to "wordsmith" it to deflect blame and make sure nobody looks bad, and all the lawyers need to bless it so that it's not admitting anything. I bet you there's a Word doc being frantically E-mailed around all day, needing to be approved by 25 people before it reaches the light of day.
How did you verify that a software update can 1. Occur during driving operation of the vehicle and 2. results in vehicle power loss?
I worked in an auto supplier years ago and there where several protections in place to prevent the risk of update corruption on safety related components. One of the simplest one the UDS programming session having entry protections related to vehicle speed, vehicle driving mode, etc.
imho the occasional mixup is going to happen, and eventually it'll be big like this or like Crowdstrike, but pushing these out on Fridays means the critical staff isn't there to help. The people who could have communicated this stuff to customers and dealerships were in bed when people got into their jeeps at 6am on Saturday after an overnight update.
I believe crowdstrike's update was on a Friday night as well.
Unless its a serious security bug, it can wait for not only for better QA testing but also for next Tuesday. Read-on Fridays need to be an industry-wide thing.
To me the bigger issue is that the infotainment system can affect the core function of the vehicle. That seems completely unacceptable, regardless of when an update is pushed out. The two systems should be separate with the infotainment system as the lesser important and unable to actually effect the core system.
Honestly the only thing that's going to change this is criminal liability for safety related software bugs. Otherwise, it's just business as usual and the business for the last 15 years has been cutting QA and asking developers to do testing themselves, which is literally impossible for a lot of software due to lack of proper staging environments and large permutations of configurations.
Personally, I would return the vehicle as defective after an issue like this. No way I'm going to trust the lives of family, friends and myself to a company like this.
Why do you let your vehicle update without supervision and knowing exactly what the update entails (what it does)?
If you knew upates were occurring why didn't you stop them by not allowing internet access and or disabling the web/net hardware?
I find it very odd, I never allow any hardware unfettered internet access let alone update its firmware. Experience has taught me that that's a recipe for trouble.
I recently worked at a big home lighting company, working on the OS of the router device that communicates with the light bulbs themselves and the internet/user.
Our OTAU architecture uses A/B system updates [1]. Core idea is that both the kernel and the rootfs (read-only) partitions had 2 different bootslots in storage, and the OTAU would only write to the bootslot that is unused. Hence, if something went wrong, the system would automatically fallback to the previous version by just switching the bootslot used. Over the numerous years that that architecture was used, I couldn't find a single post-mortem that resulted in devices being bricked. Something to note is that the rootfs partition was overlaid with a writable partition for persisting state data etc.
Now that was a $two-figure USD device, not a $5/6-figure USD electric SUV. Is this a cost-cutting measure? At those price levels, doubling your NAND size is not even half of a percent of the total cost of the vehicle.
Unless there was a serious issue that the used bootslot corrupted the unused bootslot, then I don't see how this could have happened.
It's saddening that car manufacturers are so unserious about the code they're deploying.
I've worked in both IoT lighting and automotive, so I'm comfortable comparing the two. This also isn't offered as a defense.
The big auto OEMs are just as sensitive to absolute BOM cost optimization, regardless of the percentage increases. I don't think this was a bootslot issue though, regardless of the word "bricked". Even as backwards and ill-advised as auto software can be, generally accepted practice is that updates are impossible while the vehicle is in motion. This is usually enforced by systems shared across multiple OEMs through the tier system.
The situation sounds more like a disastrously buggy new firmware.
I wouldn't put either past stellantis though. The auto industry already scrapes the bottom of the proverbial barrel sometimes, and stellantis isn't exactly known for their top of market compensation.
Until this year, my Hyundai let me install updates while driving. Apparently the nhtsa or someone made them stop because they weren't meeting the standard of being able to activate the backup cam within 2 seconds
This is generally how other devices work as well - for example all Android devices and Android-derivatives (which many of these cars are!) use a similar A/B partition to prevent bricking.
It definitely reduces the risk of updates, but it absolutely doesn't eliminate it.
The A/B updater itself is a surface area - especially if the logic is complex and there are other child devices that are updated at the same time (likely for cars). In that case you're not just coordinating between two independent partitions, you're coordinating between 2 * N partitions, half of which have dependencies on each other.
Also, the key bit of the mechanism is that upon successful boot the new partition is flagged as "good", which causes flags to be set to assert that the update was successful and the backup partition is no longer needed. That logic can (and does) fail - if your failure point occurs after this checkpoint you're hosed still because you're past the point of no return.
Making that worse is that in most systems you want the "it's all good" checkpoint to occur early - you don't want to, for example, wait multiple minutes for all user services to come up. But that also means that if a critical failure happens in said services, you're past the checkpoint.
> Now that was a $two-figure USD device, not a $5/6-figure USD electric SUV. Is this a cost-cutting measure? At those price levels, doubling your NAND size is not even half of a percent of the total cost of the vehicle.
Could just be a competence and priorities problem. If it's cost cutting, it feels way more likely that some PM cut some story from a sprint to hit a deadline (and objections were either not raised or ignored), than they did some engineering analysis and explicitly decided to save $3 per vehicle by cutting the NAND size.
Edit: Actually, I don't think that technique would have helped, the problem wasn't a botched update, but a seriously buggy one. From the OP:
> The buggy update doesn't appear to brick the car immediately. Instead, the failure appears to occur while driving—a far more serious problem.
> Edit: Actually, I don't think that technique would have helped, the problem wasn't a botched update, but a seriously buggy one. From the OP:
That and combined with general refusal of new automotive bootloaders to downgrade. You can go only up in versioning. So even that you could have working version on second partition, it will never get loaded because it has lower version than currently one you are running.
1) Total cost of the vehicle does not matter. What does matter is the operating margin. Half a percent of the total cost of the vehicle will move them from 2% margin to 1.5% margin. (Ford has operating margin of 2% as an example)
In other words an increase in 0.5% cost of total vehicle will reduce their profits by 25%.
That’s a huge number now! Note also that car manufacturers are in a bad spot because their volumes are fairly low (smartphone = 1M/yr, car = 40k/yr) and have harsher requirements for chips, driving the cost way up.
2)AB updates are great, but they can still fail or get soft locked. Especially important around code when you configure the slot to be good and when bad.
> the system would automatically fallback to the previous version by just switching the bootslot used.
That's the hard part though.
It's shockingly common in my experience to have an A/B boot setup, but no actual logic in the userspace application to switch back to the other partition if something goes wrong. It's just a defense against somebody pulling the plug during the OTA, it doesn't protect against software bugs at all.
I once managed to brick a PC motherboard that advertised "dual BIOS". It didn't fallback to the previous version after a botched BIOS update.
It's totally possible that the update corrupted the other bootslot as well. If those blocks aren't off-limits to the updater program, it's just an off-by-one error waiting to happen. Slot 0 or slot 1?
Another possibility is that the updated version booted up just enough not to trigger the automatic fallback, and then got stuck in a loop.
I have heard anecdotally that auto manufacturers are sensitive to a price change less than $5/vehicle. This is better than some industries that are sensitive to $1.
What could easily have happened is that the negotiators didn't include A/B updates in their spec, or they only specced A/B updates at 1GB OTA size.
They do their usual hammering on price, and the head unit or ECU manufacturer gave them some savings by cutting storage space to the bone.
Maybe it was still enough for A/B updates, until the usual software bloat took the updates past the critical limit.
They could still do a safe update by doing an A/B/A update (where B is a shrunken, update-only OS), but that requires development time, and the engineers should already be working on the next vehicle.
Worked for them. Corporations with many brands in their portfolio might discuss for weeks over price differences of components of 0.20 Euro. That‘s twenty Euro cents difference for e.g. a USB connector. If you expect that a vehicle platform sells in the 10s of millions over its lifetime, you‘re talking real money very quick!
We used to do that with device that where in difficult to reach places with harsh uptime requirement! Think industrial routers and protocol converters. I think it pays for itself very quickly. Sending someone for such a device can get expensive.
Brick is now slang for a lot of fail conditions that aren't classically 'bricked.' This has become really common I've noticed. Honestly, this ship has sailed and isn't even worth fighting anymore. Its like Xerox asking people to stop calling copies Xeroxes.
We just never bothered to develop a new term. Maybe 'soft-bricked?' 'Semi-bricked?' I would like journalists at least to start using more accurate terms, but 'bricked' I imagine gets a lot more engagement and ad impressions, so here we are.
I’m sorry, but you’re incorrect the vehicle completely shutting down while driving and not working again until you put it into park and then it’s shutting down five minutes later is effectively bricked and extremely dangerous. Myself and my family almost died just trying to get home from dinner. It was a complete loss of propulsion and power steering.
I for one am always grateful when things are engineered thoughtfully and with redundancy as it is symbolic of respect for the people who are your customers. Especially in something as important as a car, "can be bootstrapped from a central computer" - when? how easily? how reliably? - is not good enough because things will inevitably go wrong for some portion of the user base.
Well, on the positive side, at least they were stationary unlike these vehicles. Don't get me started on botched OTA updates, there are so many ways companies get those wrong it's not even funny.
All those words you are saying, it's quite possible the sub-contractor to the sub-contractor to the sub-contractor in a foreign low-cost country that actually did the work has absolutely no idea what any of that means, and they are doing the bare minimum to deliver
Problem with that statement is some of these “foreign low-cost” countries are building great cars while American vehicles have a global reputation for being garbage.
The only American-made vehicle that sold in any volume outside the US was Tesla and that is already over.
Why wouldnt a foreigner know what this means? This seems very xenophobic. And if US/Euro management is hiring these groups and not giving them requirements for redundancy then guess who is at fault? Not the contractor.
I rented a Jeep Wagoneer recently and found it to have such comically glitchy electronics that this comes as no surprise. The second day we had it, the liftgate stopped latching entirely, it beeped and popped some error messages on the dashboard and simply wouldn't latch shut at all, no matter what we did. Searching the internet produced lots of people with the same problem, reporting that it required a software update to fix. There was no manual override to the electronic latching mechanism.
Luckily we were near a location of the rental car company—rather than deep in the middle of nowhere where we were headed—and exchanged it for another of the same model, which was all they had available. The next 1000-something miles we drove were filled with endless weird glitches:
- When a passenger plugged in their Steam Deck in the back, the entire infotainment system cut out and went black, including the instrument panel, and then started glitching in and out until they unplugged it.
- When parking, the driver's seat would retract slightly to make it easier to get out, but it never moved forward again, so the seat would get further back at each stop until it was manually repositioned.
- The entire drive the system flashed an un-dismissable error about a rear seat latch, which seemed completely functional.
- The TPMS light went on and off periodically as it seemingly lost and then regained signal from one wheel or another.
- The system flashed errors related to the automated cruise control being unavailable/broken at random times.
- The electronic parking brake kept applying itself while briefly paused in parking lots.
- There was something inscrutably wrong with the climate control that we never really figured out where sometimes it'd just get hot inside the car despite no change to the AC settings.
When we got back I found tons of people online talking about similar (often worse) issues. Incredibly terrible for any new vehicle, never mind one that costs $80k.
Honestly, unsurprising. Jeep and Stellantis/Dodge in general has horrible quality control and extremely poor electrical designs. They have a huge enthusiast community that will be happily apologize away the copious amounts of flaws. Frankly, nobody should ever buy their vehicles, it's just robbing yourself.
I own a 2002 Grand Cherokee which sometimes will have a 10A+ power drain for no apparent reason. Of course it doesn’t do it when I’ve got my voltmeter on it, except once (when the 10A fuse in my Fluke blew). I resigned myself to unplugging the battery or leaving it plugged in to a high current battery charger at home, and leave it running if I drive it somewhere.
I rented a Jeep Liberty or Compass circa 2018 whose headlights were permanently in DRL mode: couldn’t turn them off or on. Fortunately I didn’t need to drive at night.
In 2017, rented a 300 with 500 miles on it; the infotainment was completely broken, which hosted the controls for the seat heaters and temperature setting. It was well below zero in Minneapolis but we had to drive around with our windows down because the fancy climate system defaulted to max heat blast + max heated seats based on ambient temperature.
Long ago I had a 1996 Neon where the wiring harness started to fail, and the speedometer would stop working. Later on the oil light would come on despite oil pressure being fine. Eventually the entire car just quit running at all at random - nothing but a dim oil light. I sold the car for scrap for $65 since I got tired of being randomly stranded.
So what I’m saying is that it sounds like Chrysler has managed to actually keep doing the same thing for 29 years: electrically unreliable vehicles.
I own a Jeep Wrangler, and you're right the electronics are terrible. The rest of the vehicle is really solid though. The only problems I've had with it in three years are electronic in nature. And I've really pushed it to the limits: Colorado Passes, Utah Dessert, Montana backroads. I drove it to the Arctic Ocean and back on the Dempster.
Still there is no excuse for how terrible the electronics are in Jeep / Dodge (I'm assuming all Chrysler) vehicles. And it's been that way for decades.
It’s too bad because the wagoneer is the best designed car in the segment, inside and out for the most part.
I have a somewhat bad back and want something that I can occasionally work from, so a big space, comfy middle seats, a wide center console. Car makers for some reason refuse to make essentially a Tahoe but shorter wheelbase / 2 row which would be ideal. Instead you have to go with the full size to get full-width.
But out of those, only American brands seem to understand the utility of blocky interiors. Armada and all the Japanese and Korean large SUVs always use swooping rounded edges which really reduce utility.
But the American brands are all less reliable and struggle with consistent quality.
> - When parking, the driver's seat would retract slightly to make it easier to get out, but it never moved forward again, so the seat would get further back at each stop until it was manually repositioned.
This is AWESOME.
October is SPOOKY month for Stellantis software, apparently.
Overall it sounds like changes were applied, internally, and not reverted - as if they changed something in the Transaction handling for multi-step car systems updates.
You mention something about it continuously getting hotter ..
> it'd just get hot inside the car despite no change to the AC settings
I felt a little bad but laughed out loud reading some of the other stories of peoples' problems with the Wagoneer—one person reported that the first night they brought it home brand new from the dealer, one of the headlights wouldn't turn off no matter what they did and just stayed on the whole night shining against the house. Spooky!
My friends and I rented a Wagoneer and found that the electronic feature to flip the rear seats down worked while there were people in those seats, while the vehicle was in motion!
So of course every hour when the boys weren't paying attention POP the driver would unlatch their seats and headrests lmao
Horrible safety guardrails but a good time was had by all.
I've had a Jeep for a few months, and it bothers me so much that the entire community is about modifying the vehicle as much as possible, but they still come with this locked down OS.
If any car could be the champion of OpenSource, it is a Jeep Wrangler, but they're using an OS made by SiriusXM for some reason.
Isn't Jeep the company that introduced infotainment pop-up ads that play at the stop light? I doubt they'd want you loading an open source OS replacement to avoid that.
I can't for the life of me understand why infotainment systems knock so many engineers for a loop. Is there a particular reason (industry/domain-specific) beyond just low-quality software development?
My Mazda 3 (2018) just had a class action lawsuit for its infotainment system which, completely at random after years of normal operation, starts clicking on menu items and scrolling about the settings (only to stop and not do it again for a couple of months). It can get so bad you just have to disconnect any devices and drive in silence/with the AM/FM radio.
I worked at a company that did software for these connected infotainment system. They cost cut those things to the bone, minimal ram, minimal cpu, shit screens. Even in the high end models.
Gotta remember that the car radio has always been a cheap gimme.
Gotta remember that the car radio has always been a cheap gimme.
Not really. Some of the hardware that you could get in the 1950s-1970s timeframe was great. Heavy chrome knobs and bezels, permeability-tuned front ends with separate RF stages... electromechanical mechanisms that seemed like witchcraft when I took them apart as a kid, and would still be cool to play with today.
it's the consequence of not vertically integrating, having 20000 different ECUs each for a specific purpose and trying to nickel-and-dime suppliers on all of them, and the lack of urgency that traditional manufacturers and tier-1 suppliers have for adopting modern software development practices
Hardware companies outsource these things to the lowest bidder in "best cost countries". At home you have a couple "engineers" who track requirements, but are software illiterate. In the "best cost country" you have dozens/hundreds of people who have absolutely no investment in the product and are not particularly skilled, and who get paid so that that engineer can make a checkmark after some requirement in the shortest amount of time. Nobody in that entire pipeline cares that the system feels awful to use, that it glitches sometimes or that the CPU is totally over utilized.
Tesla was revolutionary because they actually had inhouse software developers, who could build software.
I recently did some testing of Bluetooth connecting an Android phone to a reasonably new Mercedes. Being a "luxury" brand, you'd think the Mercedes would have good infotainment software, but I found at least 5 bugs in the GUI in about 1 hour of testing, and I wasn't particularly looking for bugs, just testing what I thought would be the happy paths for Bluetooth connection. The Android phone, on the other hand, did its job flawlessly.
I know software and embedded systems well enough to know all of the issues I found were preventable, if anyone cared.
The car seems well built in many other respects. It doesn't look like the problem is engineering ability.
(See also: Set-top box GUIs that are painfully slow to render menus, scroll, search etc. on hardware that I know can render 10-100x faster when programmed to.)
As you alluded to, the answer is they don't care. Car companies look at software like it's any other line item on the BOM. Like a bolt or a gasket: Source it as cheaply as possible and spoon it onto the product somewhere on the assembly line. I see fit-and-polish mistakes all the time in car infotainment. Text that can't handle unicode, icons that are misaligned by 1 or more pixels, connections dropping and coming back, audio mixing problems, things drawing outside their "windows." Nobody cares--they get to the drop dead date when the software needs to be on the assembly line, hand it over, and start flashing devices.
Problems like this is why I got a 2025 Suzuki Jimny XL.
I don't need a computer on wheels, it has all the ingredients for disasters but people keep ignoring it. XL:
1. No firmware update,
2. No OTA updates, you get what you paid for;
3. No internet access;
The most important thing:
* Standard key (AU version), no keyless ignition!
As it stands now, any car that is keyless ignition can be stolen by OBD devices sold at eBay and AliExpress.
The newer the car, the worst.
Toyota new cars in Australia are being stolen by drilling its passenger door which grants you access to the OBD located on the passenger side, hook the OBD device that cost less than AUD50 and you are driving an over AUD100k car away like you own it.
I am not even getting into cars systems have zero security, I remember watching in early 2000s, a hacker taking control of the reporter's car while on a highway and made the car stop. The reported had to change his underwear!!
Things got a lot worse 25 years later.
Back to Jeep 4XE Hybrid cars, they are 2025 models and people bought it even after everything that is going on around Jeep.
It is hard to blame only the company on this.
This is disturbing. There is absolutely no valid reason to make OTA updates to your ECU or other essential components. Never.
Ever. If there ever was a need to do such an update, it should be made in the dealership by a professional who can roll it back if there’s a problem. Automakers have become far too complacent while at the same time over-automating everything and profiteering by turning things into a subscription model. This is why so many car enthusiasts (myself included) prefer older cars.
Readit News
- As of Monday 8am ET, zero legitimate communication from any Jeep-related accounts on any social media platform, or any other form of acknowledgement from the company (unless I've missed something?)
- I only found out about the issue after finally searching a few Jeep groups on Facebook (of all places) to see if anyone else was experiencing the weird failure mode I was after the update.
- The only remotely-official info was from a 'JeepCares' account (which is ran by Jeep) on some random off-roading forum? We were seriously all living off of screenshots from this forum, and the advice coming from the JeepCares accounts was contradictory: they claimed that the Uconnect update was separate from the telematics update, and that there was no way to stop the telematics update if the vehicle received it. Later they gave advice to defer the Uconnect update, making it sound like they were coupled.
- Due to the lack of info from Jeep, people were coming up with all kinds of "if you reboot Uconnect while the Jeep's in ACC mode, it clears the check engine light". This probably did clear the CEL but didn't fix the fault.
- There is no way to tell if you received the bad update.
- There is no way to tell if you received the 'fix' either.
- Dealerships have literally no idea what is going on.
- You're basically at risk of your Jeep going limp (power loss, unable to safely make it to the shoulder) and being stranded on the highway, even as I write this.
This seems extraordinary.
I was going to ask: Are you really saying they kill the vehicle's power system, effictively the engine, while the vehicle is being driven on the highway?
But no need to ask, the article says yes, that's what is reported:
> Instead, the failure appears to occur while driving—a far more serious problem. For some, this happened close to home and at low speed, but others claim to have experienced a powertrain failure at highway speeds.
Wow.
https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...
This has happened to me twice with a Nissan Leaf. I paid money to get a read out from the computer system, and there were no timestamps on the screens of data.
Modern cars "computers on wheels" are dreadful.
Is it possible to disconnect the power from the radios used for "over the air" nonsense? Then at least they would be stable.
A GPS update kills your entire powertrain. Appears to also engage parking for some users, super dangerous. Catbones, "Almost died on the thruway today ... with an 18-wheeler behind me. ... Jeep died, locked its hand brake and jolted so hard my face almost ended up in the steering wheel at 70mph." [1]
[1] Wrangler 4xe forum, JeepCares and Catbones accounts: https://www.4xeforums.com/threads/wrangler-4xe-ota-update-10...
Personal bet: Jeep accidentally enabled the remote kill switch for repossessing automobiles. [2] Possibly the "impaired driver" kill switch. [3]
[2] Stateline, Late Payment Kill Switch: https://stateline.org/2018/11/27/late-payment-a-kill-switch-...
[3] Trackhawk, Federal Kill Switch Law: https://trackhawkgps.com/blog/kill-switch-law
The entire box it’s on isn’t powered while the plane is in motion (“wheels on ground”). It’s shut off before preflight and doesn’t turn back on until the plane is on the ground. The service my code is part of is responsible for queuing updates and downlinking telemetry. Updates are manual and obviously you can’t run them while in motion if the box they are on doesn’t even have power.
Cars probably don’t have to go this far, but there’s a continuum and they’re clearly in the wrong part.
My anecdata is that my car won't update its software without the owner explicitly requesting it. And then, it will only do it if the car has something like 50% charge, hasn't been used for an hour, and nobody is inside.
I once tried to do the update while I was inside, and it refused.
However in classic Jeep style they just can't get reliability down, and the PHEV part seems too complicated for them.
If it was just reliable it would still be the best selling PHEV in America, they let that go.
There is no sign of the 2026 Wrangler 4XE it might be canceled like the Gladiator version...
The times that I have been given a jeep rental while on vacation or work trips have always left me disappointed with the vehicle.
Under time pressure and confirmation bias they signed off on code that was giving off signs of being broken, pushed it, and now key staff are either on airplanes, out of coverage on their phones, or cannot work entirely from memory and don’t have their computers with them because vacation.
I worked in an auto supplier years ago and there where several protections in place to prevent the risk of update corruption on safety related components. One of the simplest one the UDS programming session having entry protections related to vehicle speed, vehicle driving mode, etc.
I believe crowdstrike's update was on a Friday night as well.
Unless its a serious security bug, it can wait for not only for better QA testing but also for next Tuesday. Read-on Fridays need to be an industry-wide thing.
If you knew upates were occurring why didn't you stop them by not allowing internet access and or disabling the web/net hardware?
I find it very odd, I never allow any hardware unfettered internet access let alone update its firmware. Experience has taught me that that's a recipe for trouble.
Our OTAU architecture uses A/B system updates [1]. Core idea is that both the kernel and the rootfs (read-only) partitions had 2 different bootslots in storage, and the OTAU would only write to the bootslot that is unused. Hence, if something went wrong, the system would automatically fallback to the previous version by just switching the bootslot used. Over the numerous years that that architecture was used, I couldn't find a single post-mortem that resulted in devices being bricked. Something to note is that the rootfs partition was overlaid with a writable partition for persisting state data etc.
Now that was a $two-figure USD device, not a $5/6-figure USD electric SUV. Is this a cost-cutting measure? At those price levels, doubling your NAND size is not even half of a percent of the total cost of the vehicle.
Unless there was a serious issue that the used bootslot corrupted the unused bootslot, then I don't see how this could have happened.
It's saddening that car manufacturers are so unserious about the code they're deploying.
[1] https://source.android.com/docs/core/ota/ab
The big auto OEMs are just as sensitive to absolute BOM cost optimization, regardless of the percentage increases. I don't think this was a bootslot issue though, regardless of the word "bricked". Even as backwards and ill-advised as auto software can be, generally accepted practice is that updates are impossible while the vehicle is in motion. This is usually enforced by systems shared across multiple OEMs through the tier system.
The situation sounds more like a disastrously buggy new firmware.
I wouldn't put either past stellantis though. The auto industry already scrapes the bottom of the proverbial barrel sometimes, and stellantis isn't exactly known for their top of market compensation.
It definitely reduces the risk of updates, but it absolutely doesn't eliminate it.
The A/B updater itself is a surface area - especially if the logic is complex and there are other child devices that are updated at the same time (likely for cars). In that case you're not just coordinating between two independent partitions, you're coordinating between 2 * N partitions, half of which have dependencies on each other.
Also, the key bit of the mechanism is that upon successful boot the new partition is flagged as "good", which causes flags to be set to assert that the update was successful and the backup partition is no longer needed. That logic can (and does) fail - if your failure point occurs after this checkpoint you're hosed still because you're past the point of no return.
Making that worse is that in most systems you want the "it's all good" checkpoint to occur early - you don't want to, for example, wait multiple minutes for all user services to come up. But that also means that if a critical failure happens in said services, you're past the checkpoint.
Could just be a competence and priorities problem. If it's cost cutting, it feels way more likely that some PM cut some story from a sprint to hit a deadline (and objections were either not raised or ignored), than they did some engineering analysis and explicitly decided to save $3 per vehicle by cutting the NAND size.
Edit: Actually, I don't think that technique would have helped, the problem wasn't a botched update, but a seriously buggy one. From the OP:
> The buggy update doesn't appear to brick the car immediately. Instead, the failure appears to occur while driving—a far more serious problem.
That and combined with general refusal of new automotive bootloaders to downgrade. You can go only up in versioning. So even that you could have working version on second partition, it will never get loaded because it has lower version than currently one you are running.
1) Total cost of the vehicle does not matter. What does matter is the operating margin. Half a percent of the total cost of the vehicle will move them from 2% margin to 1.5% margin. (Ford has operating margin of 2% as an example)
In other words an increase in 0.5% cost of total vehicle will reduce their profits by 25%.
That’s a huge number now! Note also that car manufacturers are in a bad spot because their volumes are fairly low (smartphone = 1M/yr, car = 40k/yr) and have harsher requirements for chips, driving the cost way up.
2)AB updates are great, but they can still fail or get soft locked. Especially important around code when you configure the slot to be good and when bad.
It's also more dynamic than your presentation. They have a little bit of pricing power, so a small increase doesn't all come out of the margin.
That's the hard part though.
It's shockingly common in my experience to have an A/B boot setup, but no actual logic in the userspace application to switch back to the other partition if something goes wrong. It's just a defense against somebody pulling the plug during the OTA, it doesn't protect against software bugs at all.
It's totally possible that the update corrupted the other bootslot as well. If those blocks aren't off-limits to the updater program, it's just an off-by-one error waiting to happen. Slot 0 or slot 1?
Another possibility is that the updated version booted up just enough not to trigger the automatic fallback, and then got stuck in a loop.
What could easily have happened is that the negotiators didn't include A/B updates in their spec, or they only specced A/B updates at 1GB OTA size.
They do their usual hammering on price, and the head unit or ECU manufacturer gave them some savings by cutting storage space to the bone.
Maybe it was still enough for A/B updates, until the usual software bloat took the updates past the critical limit.
They could still do a safe update by doing an A/B/A update (where B is a shrunken, update-only OS), but that requires development time, and the engineers should already be working on the next vehicle.
Dead Comment
(Most computers in a car don't need duplicate partitioning because they can be bootstrapped from a central computer)
We just never bothered to develop a new term. Maybe 'soft-bricked?' 'Semi-bricked?' I would like journalists at least to start using more accurate terms, but 'bricked' I imagine gets a lot more engagement and ad impressions, so here we are.
I'm curious if failing to do that opens Jeep up to legitimate lawsuits.
The only American-made vehicle that sold in any volume outside the US was Tesla and that is already over.
Luckily we were near a location of the rental car company—rather than deep in the middle of nowhere where we were headed—and exchanged it for another of the same model, which was all they had available. The next 1000-something miles we drove were filled with endless weird glitches:
- When a passenger plugged in their Steam Deck in the back, the entire infotainment system cut out and went black, including the instrument panel, and then started glitching in and out until they unplugged it.
- When parking, the driver's seat would retract slightly to make it easier to get out, but it never moved forward again, so the seat would get further back at each stop until it was manually repositioned.
- The entire drive the system flashed an un-dismissable error about a rear seat latch, which seemed completely functional.
- The TPMS light went on and off periodically as it seemingly lost and then regained signal from one wheel or another.
- The system flashed errors related to the automated cruise control being unavailable/broken at random times.
- The electronic parking brake kept applying itself while briefly paused in parking lots.
- There was something inscrutably wrong with the climate control that we never really figured out where sometimes it'd just get hot inside the car despite no change to the AC settings.
When we got back I found tons of people online talking about similar (often worse) issues. Incredibly terrible for any new vehicle, never mind one that costs $80k.
I rented a Jeep Liberty or Compass circa 2018 whose headlights were permanently in DRL mode: couldn’t turn them off or on. Fortunately I didn’t need to drive at night.
In 2017, rented a 300 with 500 miles on it; the infotainment was completely broken, which hosted the controls for the seat heaters and temperature setting. It was well below zero in Minneapolis but we had to drive around with our windows down because the fancy climate system defaulted to max heat blast + max heated seats based on ambient temperature.
Long ago I had a 1996 Neon where the wiring harness started to fail, and the speedometer would stop working. Later on the oil light would come on despite oil pressure being fine. Eventually the entire car just quit running at all at random - nothing but a dim oil light. I sold the car for scrap for $65 since I got tired of being randomly stranded.
So what I’m saying is that it sounds like Chrysler has managed to actually keep doing the same thing for 29 years: electrically unreliable vehicles.
Still there is no excuse for how terrible the electronics are in Jeep / Dodge (I'm assuming all Chrysler) vehicles. And it's been that way for decades.
I have a somewhat bad back and want something that I can occasionally work from, so a big space, comfy middle seats, a wide center console. Car makers for some reason refuse to make essentially a Tahoe but shorter wheelbase / 2 row which would be ideal. Instead you have to go with the full size to get full-width.
But out of those, only American brands seem to understand the utility of blocky interiors. Armada and all the Japanese and Korean large SUVs always use swooping rounded edges which really reduce utility.
But the American brands are all less reliable and struggle with consistent quality.
This is AWESOME.
October is SPOOKY month for Stellantis software, apparently.
Overall it sounds like changes were applied, internally, and not reverted - as if they changed something in the Transaction handling for multi-step car systems updates.
You mention something about it continuously getting hotter ..
> it'd just get hot inside the car despite no change to the AC settings
.. which is also f'in nuts.
So of course every hour when the boys weren't paying attention POP the driver would unlatch their seats and headrests lmao
Horrible safety guardrails but a good time was had by all.
https://www.stellantis.com/en/news/press-releases/2025/octob...
If any car could be the champion of OpenSource, it is a Jeep Wrangler, but they're using an OS made by SiriusXM for some reason.
I don't know that anyone has broken the head unit firmware though.
My Mazda 3 (2018) just had a class action lawsuit for its infotainment system which, completely at random after years of normal operation, starts clicking on menu items and scrolling about the settings (only to stop and not do it again for a couple of months). It can get so bad you just have to disconnect any devices and drive in silence/with the AM/FM radio.
Gotta remember that the car radio has always been a cheap gimme.
Not really. Some of the hardware that you could get in the 1950s-1970s timeframe was great. Heavy chrome knobs and bezels, permeability-tuned front ends with separate RF stages... electromechanical mechanisms that seemed like witchcraft when I took them apart as a kid, and would still be cool to play with today.
Tesla was revolutionary because they actually had inhouse software developers, who could build software.
With cars, you don't get to get a new device, it has to be consistent and keep working and you had better make it all work with a skeleton crew.
I know software and embedded systems well enough to know all of the issues I found were preventable, if anyone cared.
The car seems well built in many other respects. It doesn't look like the problem is engineering ability.
(See also: Set-top box GUIs that are painfully slow to render menus, scroll, search etc. on hardware that I know can render 10-100x faster when programmed to.)
1. No firmware update,
2. No OTA updates, you get what you paid for;
3. No internet access;
The most important thing:
* Standard key (AU version), no keyless ignition!
As it stands now, any car that is keyless ignition can be stolen by OBD devices sold at eBay and AliExpress.
The newer the car, the worst. Toyota new cars in Australia are being stolen by drilling its passenger door which grants you access to the OBD located on the passenger side, hook the OBD device that cost less than AUD50 and you are driving an over AUD100k car away like you own it.
I am not even getting into cars systems have zero security, I remember watching in early 2000s, a hacker taking control of the reporter's car while on a highway and made the car stop. The reported had to change his underwear!! Things got a lot worse 25 years later.
Back to Jeep 4XE Hybrid cars, they are 2025 models and people bought it even after everything that is going on around Jeep. It is hard to blame only the company on this.
Me being in FREEDOM USA FREEDOM I cannot drive one of these as Suzuki isn't doing business here anymore .. since 2010.
Enjoy yours, though !!