Understand low-power modes for MCUs
Q: I know there are a number of low power-consumption modes for MCUs. Can you tell me what they are and which one saves the most power?
A: Whether you’re designing an embedded system for a tablet or an automotive instrument cluster, power management plays a key role in the success of your product. You will want an MCU that gives you enough power management choices that you can make effective trade-offs between performance and lifetime for your application. Different MCUs offer different low power-consumption modes depending on the level of sophistication, but there are some basic modes that show up across the board. I’ve listed these in order of least power savings to highest, and also provided some details about each one.
- Sleep Mode: All MCU resources such as timers, I/Os, and buses remain active; only code execution of the CPU halts. The CPU will resume code execution on every incoming interrupt.
- Timer (Watch) or Clock Mode: Code execution of the CPU stops and all MCU resources stop except a timer; the latter includes a clock source for the timer to generate necessary wake-up events for cyclic wake-up of the MCU. The MCU will resume into a run mode on wake-up events that can be generated from the timer or from external interrupts or a reset input.
- Stop Mode: Code execution of the CPU stops and all MCU resources stop. In addition, all clock sources shut down. Wake-up from this mode to resume run mode is only initiated by external events coming in via external interrupts and resets.
Note that the Timer (Watch) Mode and the Stop Mode can be combined with power shutdown of large parts of the MCU. Some MCUs such as Spansion’s automotive controllers support some amount of so-called standby RAM that is kept powered to store the application information required to be available after a restart of the system. For more information related to low power-consumption modes and power levels for each mode, please refer to the respective datasheet for the MCU you’re using.
Of course, multiple power-saving modes for your MCU are not much use if they’re incorrectly implemented. Considerations regarding maximum wake-up time, efficiency, and performance need to be taken into account, to name a few. For additional information on this topic, read “Using MCU Power Management Options to Optimize System Efficiency.”
Q: Can you tell me the differences between MTBF, FIT, and MTTF? How are they calculated?
A: The terms MTBF, FIT, and MTTF are often used when discussing the reliability of IC devices or systems containing ICs, so it’s a good idea to be sure everyone knows what they are and the differences between them. These methods for determining reliability are valuable when customers are deciding which products to purchase for their respective applications.
Let’s start off by defining what these terms mean before diving into the details.
- MTBF: Mean time between failures—the predicted elapsed time between inherent failures of a device or system during operation
- FIT: Failure in time—the number of failures anticipated in an agreed-upon time interval (typically 1 billion hours)
- MTTF: Mean time to failure—the amount of time predicted to elapse before the device or system fails catastrophically
To help clarify the nuances, let’s start with a graph that can help illustrate the normal lifetime of a component or system (see figure 1). This graph, called the bathtub curve, contains three periods: an infant mortality area at the beginning of a product lifetime, a normal lifetime with a relative constant failure rate, and an end-of-life or wear-out period during which failure rates increase.
When should we use the terms MTTF and MTBF? As the predicted elapsed time between inherent failures of a device or system during operation, MTBF belongs to a model that assumes the failed system is immediately repaired. Since a semiconductor device is typically not repairable, we should use the term MTTF rather than MTBF when talking about memory and MCUs.
But what does MTTF really mean? Let’s start with a discussion of FIT. By definition, FIT is the number of failures that can be expected in 1 billion operating hours (109 hr). The failure calculations for FIT and MTTF are related only to the “normal life” period of a device as shown in figure 1. (By the way, for semiconductor devices, the normal life period is typically 10 years.)
The formula to calculate FIT is:
Thus, one failure within 109 hours will result in 1 FIT. Note, 109 hours represents the cumulative number of hours across all devices, for example testing 500 devices for 2 million hours each. Accelerated lifetime testing methods allow manufacturers to bring this testing into a realistic timeframe. This provides a measure of how many failures you are likely to experience in a set number of parts operated over a designated time frame.
You may be interested in knowing some typical FIT values so you can impress your engineering friends (or not). Check out table 1 for a few examples.
I promised to help you understand the difference between FIT and MTTF, and it’s probably easiest to do this by comparing the relationship of MTTF to FIT. If FIT represents the number of failures percent interval, then the mean time to those failures is given by the inverse. By using equation 1, you can actually calculate the MTTF as follows:
From these calculations, you can see how the FIT and MTTF relate to each other. As FIT values increase, the MTTF will decrease.
In general, FIT values are more commonly used in the semiconductor and component manufacturing industries. MTTF numbers, on the other hand, are more often referenced when discussing equipment or electronic modules that may contain a number of components within the unit itself. Regardless, you now know how to calculate each of them to serve your specific needs.
Q: I’m wondering how to ensure that my real-time clock (RTC) is kept accurate by using the FCR4 RTC auto-calibration feature. Can you provide me with some information on how this works?
A: First of all, as you can imagine, devices and systems in automotive applications are exposed to some very rough conditions, including wide temperature swings. By nature, these ambient temperature variations can cause device clock frequencies to change, especially when devices are in a very low power-consumption mode. In this mode, automotive applications often use a subclock (internal RC clock or 32-kHz clock oscillator) to self-generate cyclic wake-up events because the subclocks consume much less power. Changes in the clock frequency will lead to deviation of the RTC compared to a clock driven under constant or controlled environmental conditions.
To overcome this unwanted clock frequency deviation, the RTC that’s running on the low power-consuming subclock can trigger an auto-calibration cycle. This auto-calibration cycle automatically starts the MCU’s main oscillator for a short time. This main oscillator is usually a 4-MHz clock and is both more accurate and less temperature sensitive than a subclock oscillator. As a result, we use the main oscillator as a calibration reference to measure against the actual sub-oscillator. Once the calibration is done, the sub-oscillator is then again used to measure the time until the next wake-up event or re-calibration event occurs. This minimizes the impact of environmental changes on the RTC in low-power mode and minimizes the run time of the main oscillator to reduce power consumption.
Note that the auto-calibration cycle is performed in the hardware and requires no CPU interaction. You can find information here.
Q: Can you tell me how to access the external QSPI (Quad SPI) flash device when it’s connected to your FR81- or FCR4-family MCUs?
A: Of course, and this question has recently come up a few times so it’s a good one to address here. When either an FR81S- or FCR4-type MCU is used with a QSPI flash, such as Spansion’s S25FLxxx, the MCU and QSPI are connected by the high-speed SPI (HSSPI). The interface will be accessed in read mode with its contents mapped to the address space of the MCU. To obtain this, the HSSPI supports a command sequencer for read access. The sequencer generates the necessary protocol commands that are output to the QSPI flash memory (Command, Address, Read Data). For details on the commands understood by the QSPI flash device, please refer to its corresponding datasheet, such as the S25FL512S.
The command sequence can be user-programmed because it depends on the access type used between the MCU and the QSPI flash device, along with the number of MCU pins used for the connection between the devices. The minimum configuration needed would include DataI/O , Clock, and Chip Select; the maximum configuration would include DataI/O , DataI/O , DataI/O , DataI/O , Clock, and Chip Select. The selection you use may depend on your application requirements. The recommended setup would be to use all four data lines (Quad SPI configuration) to take advantage of the full performance of the respective QSPI flash. For more information, see the Spansion FCR4 MCU datasheet.
Q: My company recently started an electric car project, and we’re in the process of evaluating external communication controllers. Can you provide us with some information regarding your FlexRay controllers, please?
A: Congratulations on your new project and thank you for your request. You’re looking for an external communication controller that you can add to an existing MCU within your design. With that in mind, the device that should fit that application is Spansion’s FlexRay ASSP MB88121. The device interfaces via 16- or 32-bit external bus interfaces as well as via SPI. This device is qualified to the AEC-Q100 standard and is in use by major automotive OEMs worldwide.
You may also want to consider using one of Spansion’s MCUs with the embedded FlexRay interface, such as the MB91F527/8 MCU series for your design. You can find much more information by visiting the product and documentation pages on Spansion.com. Also, feel free to contact the Spansion Engineering Solutions engineers through our request form.
Other stories in this issue
Also in this issue
333 MHz NOR flash memory–Spansion’s new interface promises peak performance for memories and more
High-reliability flash memory captures vehicle performance data to support collision analysis and crime solving.
Scalable single-chip solutions deliver economical performance, security
A proactive approach between the customer and silicon supplier optimizes system performance by testing known issues and catching unknown ones.