Well, for a given chip, it usually just refers to a wider temperature range.
But there are other types of flash that are better suited for this environment. I see parallel and SPI NOR flash a lot in ruggedized embedded devices (usually with a minimum of 100,000 erase cycles), but they're generally a lower capacity.
I don't know the exact cause of this failure, but there are ways to design around unreliable flash too. They could partition it such that the firmware image is in a read-only partition, and it runs out of a ramdisk, with only user settings and log messages stored in a R/W partition. That may be what they're doing, and perhaps the issue is due to the software crashing when the write fails. I'm not sure.
>I don't know the exact cause of this failure, but there are ways to design around unreliable flash too. They could partition it such that the firmware image is in a read-only partition, and it runs out of a ramdisk, with only user settings and log messages stored in a R/W partition. That may be what they're doing, and perhaps the issue is due to the software crashing when the write fails. I'm not sure.
Not in this field so I might be wrong, but I'm guessing they could have also:
* Have redundant storage, failover when the first flash chip dies, and log a fault telling the user to get it looked at. Flash is cheap anyway
* Use removable storage. PCIe, M.2, proprietary, whatever. If it dies then at least you can replace it relatively cheap.
I'm interested in what other problems will surface with Teslas in the next few years. This seems like a huge design failure, I doubt it's the only one.
> when everyone has been busting ass for a long time and they just want to go home
This sounds like a smell. You should not be busting ass and have everyone feel like they just want to go home at the end of the sprint. You should be working productively every day without burning out. Perhaps the team is forced to make too many commitments? Kind of sounds like it from your other comments.
