4 ms·
Another source of bogus commands can be brownouts. When the voltage is low enough to confuse communication signals, but not low enough to prevent destructive ev
by vardump 3y ago
Another source of bogus commands can be brownouts. When the voltage is low enough to confuse communication signals, but not low enough to prevent destructive events from occurring.
- phkahler 3y ago>> When the voltage is low enough to confuse communication signals, but not low enough to prevent destructive events from occurring. I heard from a coworker that an older version of the product had bumped from a 16MHz chip to 20MHz to run more code. Chip supplier screened parts for the higher speed, but didn't cover higher speed across the normal voltage range. When supply dipped (within the old spec) switching speeds slowed. The first circuit to fail was something in the branch condition logic. This caused all conditionals to not branch, which lead to running all code in the memory space in order. That included a few instructions to.... fire the airbag. It was a rare thing, but a very big deal.
- hypothesis 3y agoI wonder if anyone else instantly gets a visual after reading your story: “Business woman on plane: Are there a lot of these kinds of accidents? Narrator: You wouldn't believe. Business woman on plane: Which car company do you work for? Narrator: A major one.”
- phkahler 3y agoI heard the story decades ago, and the problem had been fixed some years prior to that. There are undoubtedly hundreds of similar issues across the tech industry, most get quietly fixed before much damage is done. I only tell the story because it's an example of how obscure details come together in unexpected ways to cause failures. That happens everywhere.
- actionfromafar 3y agoAnd how brittle the borders we programmers see a strict, as a branching condition, "this should never happen". But in hardware, things are different. How do you even protect against such a thing you just described? Put the airbag on a diffent microprocessor?
- vardump 3y agoMaybe put some code directly before bag deployment code that disarms the system. So even if the execution reaches it directly through the branches, nothing will happen
- actionfromafar 3y agoSure but what if the address bus glitches past that block?
- vardump 3y agoMaybe put arming code somewhere completely different? Of course it's possible to create more and more improbable scenarios. That's not to say those never happen; I've seen really improbable occurrences.
- deleted 3y ago[deleted]
- onetimeuse92304 3y agoAll the stuff that counted on our board had brownout protection. And if it didn't it is relatively easy to deal with (as long as you are aware of the problem). (We may have learned a bit about noise and improved further iterations of the device, but sw change was enough.)