6 ms·
"Usually, microcontroller code is simple and reactive, with no concept of a shutdown routine." Really? Nobody uses brownout interrupts to lock down on power lo
by technothrasher 7y ago
"Usually, microcontroller code is simple and reactive, with no concept of a shutdown routine."
Really? Nobody uses brownout interrupts to lock down on power loss? I almost always do a few things as the power is fading, flagging the situation at the very least in order to clean up when power is restored.
- kartoffelwaffel 7y agoAlso why not chuck a capacitor in the mix to provide a little power buffer to shutdown the filesystem gracefully.
- pantalaimon 7y agoIt adds quite some space and probably costs as much as the MCU.
- keithnz 7y agonot as simple either, you still need to detect that the power is gone or fading independent of the capacitor...which all adds up
- deleted 7y ago[deleted]
- kabdib 7y agoYeah, paying thirty cents for a capacitor to coddle a ten-cent MCU doesn't make a bunch of sense. Much cheaper to teach your software folks how to write transactional updates to that flash. Typically you pay a small speed penalty to get update atomicity (in addition to having a more complicated implementation).
- delfinom 7y agoMany MCUs do not appreciate slow rise-times when using their internal regulators. Then you start oversizing your regulator or providing them replacement regulators. Which then opens more cans of worms, etc, etc.
- leggomylibro 7y agoMany voltage regulators have 'power good' pins that you can tie to the MCU's reset line, though.
- neltnerb 7y agoAnd if you don't have this, I posted this circuit example I just made for a delayed power turn on time above. Capacitor is about 5 cents, the transistors are about 6 cents each. If you need it you need it, but power good to the reset line is better. https://i.postimg.cc/Df9N8fM5/delayed-turn-on-circuit.png https://i.postimg.cc/Df9N8fM5/delayed-turn-on-circuit.png Or just put a capacitor after the reset line pullup so that it effects delayed turn on during boot.
- leggomylibro 7y agoOh, neat trick - thanks for sharing!
- Tempest1981 7y agoWhat is the voltage drop across D1 and Q2? Is that ever an issue?
- neltnerb 7y agoThe drop across D1 can be significant, using a Schottky helps. Usually within the tolerance of the power supply in any case. But a capacitor on the reset pin is pretty good ;-)
- Gibbon1 7y agoThose microcontrollers aren't reliable anyways. If you design those in you have to accept that if they have persistent state they will eventually brick themselves. If they don't have persistent state they will hang and require user intervention on a regular basis.
- Nokinside 7y agoReally. It's best not to trust on shutdown procedures for fail-safe persistence if that really is important. Use log-structured file-system and do cleanup and verification when the power is restored. When microcontrollers have brownouts, it's best to assume that you may have already garbage in the memory bus. Of course, when improved fail-safety exist just to improve reliability measured in hours and fail-safety is not critical function, all what I said is irrelevant.
- rnestler 7y agoIn one project I worked on we monitored the 24V rail and when it was dropping, the MCU had enough time to do cleanup /shutdown work until the 3.3V supply dropped.
- adamweld 7y agoanything with a 24v rail has much more power budget/bulk capacitance than most small embedded devices... so what worked there may not work well in other more common cases
- delfinom 7y agoNope. Because brown-out detectors on micros are meant for momentary glitches and unreliable. The detectors can preserve a brown out detected bit in their reset cause registers. However, they don't guarantee the micro's core will get the interrupt in time before losing power. And if the brown-out goes down to POR levels, you won't even get the brown out cause bit and instead POR. The best you can do for file systems is track a "dirty flag". You keep it set unless you power down willingly yourself.
- londons_explore 7y agoYou design the circuit... You can decide exactly how many microseconds of power you'll get between the brownout interrupt occurring and the lowest operating voltage. Your job as designer is to write the code to guarantee completion in that time. Microcontrollers don't have to suffer the same issues as app/web developers. They can know exactly how many clock cycles something will take.
- ianhowson 7y agoExcept that: (a) you don't choose how long you get because the uC manufacturer already chose. (An external brownout warning is different, and useful, but still not a good solution to the problem of FS integrity.) (b) those thresholds have nothing to do with the operating thresholds of the flash (which usually require a lot more energy to do work than the uC) (c) writing to flash is a relatively high-power operation, and if you need to erase, you're doing the highest-power operation at a time when you have no power buffer (d) warmup time to do an erase is measured in milliseconds, and you probably don't have that much power buffer The best you can do at brownout is minimize the damage, because your uC is about to switch off and/or silently inject errors.
- craftinator 7y agoBut you can just... Decide how many clock cycles you'll need to finish shutdown, calculate that power usage, then solder a corresponding power source in place. There really isn't guesswork.
- kabdib 7y agoBrownout 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.
- varjag 7y agoMy 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.
- kabdib 7y agoMight 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 ... :-) )
- varjag 7y agoAs 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.
- garganzol 7y agoMy usual design is to monitor AC powerline with opto-coupler and then enter the brownout procedure in MCU when the power loss is detected. The remaining energy stored in AC/DC converter capacitors are then used for a graceful shutdown purposes. The usual brownout procedure actions are: a) flush the current state to MCU flash memory (EEPROM) so that the work can be automatically resumed; b) wait for a power-on condition. In this way, the device is able to significantly reduce flash memory wearing. It turns to be a significant winning factor in cheaper MCUs, as they only allow about 100,000 EEPROM write cycles max. And it comes for cheap, as the only thing you need is an opto-coupler plus a bit of software wizardry.