Software Update Bricks Some Jeep 4xe Hybrids Over the Weekend

[1]: https://en.wikipedia.org/wiki/MISRA_C

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.

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.

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.

That is what I surmised from listening to the "don't do this until we fix it please" notice from Stellantis from this weekend.

Hah, curious to think that cars now have bootloaders...

I don't know that anyone has broken the head unit firmware though.

Gotta remember that the car radio has always been a cheap gimme.

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.)

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.

Tesla was revolutionary because they actually had inhouse software developers, who could build software.

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.

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.

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'm curious if failing to do that opens Jeep up to legitimate lawsuits.

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.

https://teslamotorsclub.com/tmc/threads/tesla-software-updat...

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.

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...