Hacker News new | past | comments | ask | show | jobs | submit login

Brownout detection isn't sufficient. There are many other sources of "instant stop", from simple hard-crash bugs to bit-flips in RAM that either cause a crash or multiple-bit ECC fault, take your pick because they will all turn out the lights without warning.

For consumer devices there's ESD testing, where devices are subjected to several kilovolts of zap in certification tests and are required to survive. Typically this means the device will reset and recover, but it needs to be in usable condition afterwards. If a surprise reset results in a toasted file system and a brick, you won't be able to sell the device in markets that require this testing, which is most of Europe and (I think) the US.

The right way to do a persistent store is to expect the lights to go out on any arbitrary bus cycle and design around that.

I've written a few of these. They're fun.

My understanding was if the function is interrupted on discharge, you fail the test. At least that's how our equipment was tested by an independent lab.

Might be different depending on the market. For us it was "we can reset, but we have to recover within a few seconds". I never questioned the wisdom of our hardware cert engineers.

(My experience at three different companies spread over 35 years was, if you were a software engineer helping the hardware types with ESD or RFI testing in the lab, you were definitely going to get zapped at some point. That made you part of the team, though ... :-) )

As it was put to me, if a discharge leaks through, there's really good chance that another, or 3rd, or 5th would be fatal: the device is not adequately protected. But probably that's not a big deal in some applications.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact