The infotainment system should be completely isolated from the driving system.
Also, batteries may need to be preconditioned if too hot or cold. A lot of EVs let you set your ideal departure time in a widget as opposed to using a remote though.
I can also put the car into valet mode so it won’t go fast. If I forget the valet mode password I am told I have to buy a very expensive replacement because it can’t be unlocked by a dealer.
This is a OTA vehicle update. It has the ability to update the infotainment, ECU, ECM, TCM, and BCM. Multiple manufacturers have been able to release recalls that fix major vehicle defects (safety, reliability, and performance). That wouldn't be possible without OTA updates that update core vehicle computer systems.
Unclear where this idea that OTA = Infotainment came from. I'd go as far as to say that most manufacturers can do this in 2025.
What does that have to do with OP's comment? And their point is still valid, and OTA update should not be able to brick a vehicle, regardless of the system receiving the update. And regardless if "they all can do it".
If OTA updates can update core vehicle computer systems, in ways that can correct safety, performance, and reliability problems then they can also brick that vehicle.
The manufacturer has the ability to push an update that reprograms computers that control how physical components behave in a vehicle. By the very nature of that; they can push good or evil updates.
You misunderstood what OP was saying. They claimed that an update to the infotainment system shouldn’t be able to brick the other systems in the car. The response points out the car’s OTA update subroutine has access to update every critical system in the car by design. It’s flawed logic to assume that OTA updates only affect the infotainment system.
Because to some people, the idea of an OTA update being allowed to change mission critical parts of a machine automatically without a solid rollback system is absurd, and the best way to do that is to never do OTA updates of mission critical parts at all.
Unusable devices are technically the most secure ones.
Now with hybrid or electrical drives, a motor controller is basically a package that runs its own software, which then interfaces with the rest of the car. And OTA updates can overwrite its firmware.
The only manufacturer that has avoided most issues is Toyota, since they have been doing hybrids for quite some time. Other companies are just starting on this path and to catch up, they can't be bothered to do software deep dives and figure shit out.
> The buggy update doesn't appear to brick the car immediately. Instead, the failure appears to occur while driving—a far more serious problem.
It's not worth it, but it's necessary.
> or something
Maybe do some research into the problem you're confidently asserting was trivial / read the article you're commenting on:
"...others claim to have experienced a powertrain failure at highway speeds."
https://www.reddit.com/r/Jeep/comments/1o47064/jeep_4xe_shut...
Hah, curious to think that cars now have bootloaders...
Because they work fine without them.
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.
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.
Gotta remember that the car radio has always been a cheap gimme.
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'm curious if failing to do that opens Jeep up to legitimate lawsuits.
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.
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.
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.
(Most computers in a car don't need duplicate partitioning because they can be bootstrapped from a central computer)
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.
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.
They implemented a dual redundant system similar like the dual BIOS for motherboard since 1999.
https://teslamotorsclub.com/tmc/threads/tesla-software-updat...
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.
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.
- 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.
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...
omneity•2h ago
onei•1h ago
[1]: https://en.wikipedia.org/wiki/MISRA_C