datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

The case for stand-alone reset timers in mobile devices

Travis Williams, Fairchild Semiconductor

12/9/2010 12:15 PM EST

Many of the most popular mobile devices have made the transition from being a predominately hardware based 'gadget' which provides a set of pre-defined tasks to an open ended platform for customizable software applications.

The transition has allowed mobile devices to act much more like PCs, offering end users a customizable feature set. In transitioning from a closed solution, where the hardware and software and all of the various device features are tied together, tested and verified by the manufacturer, to an open platform that must support any combination of third party software 'apps,' the likelihood of devices 'hanging' is much greater.

To support this flexibility, the system hardware also has become more complicated, with dedicated processors for multimedia, communications and power management, where each of these processors must also inter-operate flawlessly. In a new twist on an existing phrase used to describe PCs, the mobile device world has begun to refer to device lock-up as the 'white screen of death' (WSOD). In most cases the end user must resort to removing the battery to force a system reboot to resume device operation. Mobile device manufacturers are well aware of the inconvenience this causes their users and have asked their chip suppliers to provide solutions.

The first chip-makers to respond are those like Fairchild Semiconductor that have developed a line of stand-alone reset timers designed specifically to address the needs of the mobile device market. This article will explain in further detail the application need for reset timers, as well as the system solutions available. Finally, it will make the case for stand-alone reset timers as the most reliable resolution to the 'white screen of death' problem in mobile devices.

The user experience
Mobile device manufacturers are increasingly concerned about the user experience and the "total package" offering they can provide. In the very competitive market for the next great device, manufacturers must provide a seamless hardware, embedded software and user defined 'apps' solution. They must also plan for the inevitable conflicts that will arise from interoperability failures that can result in system lock up.

After working to provide a powerful platform capable of delivering a full user defined experience, there is nothing that can single handedly hurt the OEM reputation and ruin the end user experience faster than having a device lock up. Considering that mobile devices have become more than just a single function device, there is an expectation from the end user of a more sophisticated reset solution than the brute force method relied on in the past.

Not only is removing the battery to force a hard reset less elegant but is often impractical for newer device designs which may not provide access to the battery. Furthermore, it has become common for smart phones sold in the China market to have two batteries, one that is accessible to the user and one that is not. In this case it is impossible for the end user to fully remove power without disassembling the phone.

Figure 1 provides a glimpse at the level of complexity involved in the design and implementation of a smart phone. In addition to the hardware blocks shown in this figure, there is also a software layer which must run on the top level and which must coordinate the operation of the various processors. If at any time any of these system blocks becomes hung up then it can cause a ripple effect throughout the entire system.

Figure 1. Smart Phone Block Diagram





sharps_eng

12/11/2010 6:17 PM EST

I always scroll to the last page to check the writer's byline: ahah, its a Fairchild guy selling chips. Fair enough, but some of his fixit examples are just fixing terribly bad design in the original smartphones, ie the white screen of death; having to remove the battery... seems they never learn.
I hereby declare that my preference is for a separate watchdog device, but I'd use an on-chip device provided it was independent of everything except the power rails. (I am assuming we are not talking about hi-rel devices here by the way.)

Sign in to Reply



Code Monkey

12/20/2010 11:28 AM EST

The last handheld device I worked on had an FPGA. Software was expected to detect the "power" button after 3 seconds to provide the usual graceful shutdown, but for safety we put in logic to shut off power if the user holds down the button for more than 5 seconds. It's hard to imagine phone designers leaving out such a failsafe feature. Especially since Microsoft has conditioned users to expect a "reset button".

Sign in to Reply



Andrewier

12/20/2010 7:57 PM EST

Ahnnnn... A real (I mean not software) switch, anyone? After some really strong design and debuging, of course.

Sign in to Reply



Forma

12/22/2010 12:04 PM EST

The concept isn't new - there are already reset/watchdog ic chips often used in such designs. They allow communication with the Application processor to set-up a timer, whilst also providing protection for the SoC by holding the reset until the power is stable. It's know for years so above sounds more like a reminder than 'innovation'..

Sign in to Reply



Frank Eory

12/22/2010 3:08 PM EST

Doesn't every PMIC include a robust, software-proof watchdog timer reset function? Do some mobile handset designers really allocate PCB space for a separate watchdog IC? Why?

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)