One thing I see often on poorly designed embedded systems is lack of a robust system wide power supply design. Quite often little thought is put in before hand on requirements for proper power sequencing. This is the fault of the system engineer who should understand all the issues but whom usually ends up pointing the finger for a faulty system at the hardware or software designer. And while the hardware issues can be obvious, things like out of spec regulators or switching power supplies that don't switch etc. some of the software issues can be much more subtle harder to detect.

One that I have seen quite often is absolutely no regard for properly shutting down the system. Many times there is an off switch which kills all power but without ever informing the processor or OS ahead of time. Another design may force a reset on the processor and then power is cut. While the second example may be argued as preferred, both are examples of poor design.You may think that forcing a reset is the right course of action on power down but this is a very narrow view and does not take into consideration the entire system. Think about it, what if the application happened to be doing some form of write to non-volatile storage, like a SD card or hard disk, right when power was removed or the reset happened . The chances are good you will corrupt the drive sooner or later and while there are mitigations (like TFAT file system) that can reduce the chances they do not totally eliminate the possibility and should not be relied upon 100%.

I herd it argued TFAT or some form of transactional file system is all you need (indeed even some of the newer eMMC parts also have a two stage write commit feature built in) and while this may prevent file or disk corruption you can still loose data. If power is lost in the middle of a write, even with a transactional file system, you stand to lose this last data that was posted but not committed before the loss of power. Bottom line, loosing data is never a good thing and should be avoided at all costs.

A properly designed system should include a power button tied into the OS with proper power management. The OS should include a power key driver that triggers the system to properly "safe" itself before power is cut. Indeed this is how most cell phones work, when you press the power key you are presented with a menu of all kinds of shut down options. The actual "reset" button is usually hidden away on the back or in some small, mostly inaccessible place. The reset button is very rarely used and reserved for recovery from the most critical errors, like an unresponsive unit.

In the embedded world we may have a portable, battery powered system, or an AC only powered system. And while battery powered system presents even more challenges (I'll cover more about this in future blogs), AC systems can have many of the same issues. To properly "safe" system the OS will "flush" all open files and notify all the drivers to enter a low power or off state. Only then will the system suspend (in the case of a battery backed system) or enter a tight "do nothing" loop waiting for power to eventually fall off.

I have implemented a "power key" driver in the BeagleBone BSP for WEC7 and WEC2013. The physical power button is present on the BeagleBone Black and White version and is wired into the PMIC (Power Management Integrated Circuit). Pressing the button will trigger an interrupt to the AM335X processor which will intern start the shutdown procedure. The processor has the intelligence to commutate back to the PMIC via the I2C bus and can actually "cut its own throat" commanding it to remove power only after it is properly in a "safe" state.  

More on battery operation later.