AN3316 STMICROELECTRONICS | Alldatasheet
Document overview
- Manufacturer or author: Provided By ALLDATASHEET.COM(FREE DATASHEET DOWNLOAD SITE)
- PDF pages: 42
Technical content
Datasheet sections
- 1 Power consumption factors
- 1.1 Overview
- 1.2 Dynamic power reduction
- 1.3 Static power reduction
- 2 Device modes
- 2.1 Modes overview
- 2.2 Modes description
- 2.2.1 System modes
- 2.2.2 Running modes
- 2.2.3 Low Power modes
- 2.3 Key advantages of Mode Entry
- 2.3.1 Transition control
- 2.3.2 Modules/peripherals configuration
- 2.3.3 HW failure and error modes management
- 2.4 Application cases
- 2.4.1 Power-on reset phase (RESET DRUN)
- 2.4.2 Application scenarios
- 3 Consumption tables
- 3.1 Running mode
- 3.2 Low Power modes
- 3.2.1 HALT consumption
- 3.2.2 STOP consumption
- 3.2.3 STANDBY consumption
- 3.3 Peripherals
- 3.4 Consumption example
- 4 Revision history
September 2013 Doc ID 18232 Rev 2 1/42 AN3316 Application note SPC560B power and mode management Introduction This application note is intended for system designers who require a hardware implementation overview of the low-power modes of the SPC560B product family. It shows how to use the SPC560B product family in these modes and describes how to take power consumption measurements. Example firmware is provided with this application note for implementing and measuring the consumption and wake-up time of the different SPC560B family’s functioning modes.
1 Power consumption factors
1.1 Overview
- PDYNAMIC is the dynamic power contribution that depends on the supply voltage and the clock frequency through following formula: PDYNAMIC = · CV2f with: – C is the CMOS load capacitance – V is the 5 V supply voltage – f is the clock frequency
- PSTATIC is the static power contribution that depends mainly on the transistor polarization and leakage as in the following formula: PSTATIC=I STATICV So to minimize total power consumption, it is needed to minimize each dynamic/static contribution which strongly depends on clock frequency and the clock structure implemented.
1.2 Dynamic power reduction
or disable all the clocks connected to the peripherals to save power consumption. Figure 1. Peripheral clock
Figure 2. Global clock tree architecture
- Reduced number of directly clocked lines (see red circle on Figure 2)
- Reduced local clock rates through peripheral bus division (see blue circle on Figure 2) ModeEntry Module is also structured to help reduce dynamic power consumption as:
- Allows to clock-gate each peripheral independently. So, power saving can be achieved by clock-gating peripherals not used in the application.
- Allows to switch-off the CPU which is the most power-hungry part in the device. For example, while waiting for an ADC conversion to complete. CMU OSC 16MHz IRC 16MHz OSC 32KHz IRC 128KHz FMPLL RESET SAFE INT system_clk div 1 to 32 div 1 to 32 CLKOUT Selector div 1/2/4/8 CLOCK OUT SWT (Watchdog) API / RTC Peripheral Set 1 Peripheral Set 2 Peripheral Set 3 System Clock Selector (ME) div 1 to 15 div 1 to 15 div 1 to 15 Core Platform osca_clk_div irc_fast_div osca_clk osca_fast fmplla_clk div 1 to 32 div 1 to 32 oscb_clk_div irc_fast_div irc_slow_div irc_fast osca_clk oscb_clk irc_slow
1.3 Static power reduction
- Request for more performance/integration and cost reductions leading to the usage of more and more advanced and small technologies
- Carmakers’ constraints to maintain functions even when the car is switched off with a max consumption of 100µA to 1mA for the overall ECU and depending on its type, BCM, door module etc. In order to match these two constraints, ST developed the SPC560B with following features:
- Adopting 90nm technology to meet integration/costs but with using a low leakage technology (Leakage minimization)
- Subdividing device into following different PD0, PD1, PD2, PD3 power domains to meet LP function/consumption (Power Segmentation) These domains are individually disconnected from Power and so eliminates the leakage from the areas they are turned off.
Figure 3. SPC560B54/6x power domain structure
16 Mhz
Power consumption factors AN3316 8/42 Doc ID 18232 Rev 2 Notice that Power Domains shown on Figure 3 are related to SPC560B54/6x, where:
- Power Domain PD0: –a l w a y s o n – wakeup peripheries like the CAN sampler, the RTC, API, etc. – minimum RAM segment (8 K)
- Power Domain PD1: – contains all cores and the majority of peripherals – can be turned off in STOP or STANDBY modes – must be turned on in RUN modes (although there is a clock gating option for all peripherals and also a WAIT instruction for the cores to reduce power)
- Power Domain PD2: – additional RAM segment (24 K)
- Power Domain PD3: – additional RAM segment (64 K) – not supplied in standby mode, but implemented to use it in other LP-modes to reduce leakage On the other hand, to minimize static power contribution on application side, user should
- Turn-off CPU when possible, using the following autonomous "smart" peripherals: – API — Autonomous Periodic Interrupt that allows device to recover from very low power state at selected time intervals – RTC — Real Time Clock that offers precision time keeping functionality in very low power state – ADC — Analog Digital Converter with cont inuous conversion while running in low power and triggering wake-up when signal reaches certain level – DMA — Direct Memory Access that allows data transfer between peripherals minimising CPU activity – SCI — Intelligent LIN manage ment that minimizes CPU interrupts and CPU clock
2 Device modes
Mode Entry Module is a smart module implemented in SPC560B that intends at saving total device consumption. In fact it allows to manage different level of low-power modes that can reach, at minimum, few µA.
2.1 Modes overview
Mode Entry (MC_ME) is a SPC560B module that allows the user to centralize the control of all device modes and related modules/parameters within a unique module. In this way, it simplifies the implementation of mode management and thus increases its robustness. The MC_ME is based on several device modes corresponding to different usage models of the device. Each mode is configurable and can define a policy for energy and processing power management to fit particular system requirements. An application can easily switch from one mode to another depending on the current needs of the system. SPC560B modes can be subdivided in the following groups:
- System modes: All the modes (RESET, TEST, SAFE, DRUN) in which the device must be initialized and properly configured
- Running modes: All the modes (RUN0:3) used to obtain the full device performance
- Low Power modes: All the modes (HALT, STOP , STANDBY) used to minimize the power consumption
Figure 4. MC_ME mode diagram
2.2 Modes description
2.2.1 System modes
This is a chip-wide virtual mode during which the application is not active. regulators, oscillators, PLLs, and Flash modules. This is the entry mode for the embedded software. startup. It provides the unique gate to enter USER modes.
This is a chip-wide service mode which may be entered on the detection of a recoverable error. It forces the system into a pre-defined safe configuration from which the system may try to recover. TEST mode This is a chip-wide service mode which is intended to provide a control environment for device self-test. It may enable the application to run its own self-test like Flash checksum.
2.2.2 Running modes
RUNx (x=0:3) modes These are software running modes where most processing activity is done. These modes are intended to be used by software to execute full performance application routines. The availability of 4 running modes allow to enable different clock and power configurations of the system with respect to each other. SPC560B device supports WAIT instruction to stop the core with the capability to restart with very short latency (< 4 system clocks)
2.2.3 Low Power modes
This mode is intended as a first level low-power mode in which the platform is stopped but system clock can remain the same as in running mode. This is a reduced-activity low-power mode during which the clock to the core is disabled. It can be configured to switch off analog peripherals like PLL, Flash, main regulator etc. for efficient power management at the cost of higher wakeup latency. STOP mode This mode is intended as an advanced low-power mode during which the clock to the platform is stopped. It may be configured to switch off most of the peripherals including oscillator for efficient power management at the cost of higher wakeup latency. STANBY mode This is a reduced-leakage low-power mode in which only PD0 is connected and power supply is cut off from most of the device. Wakeup from this mode takes a relatively long time, and content is lost or must be restored from backup.
Figure 5. Power Domain 0 architecture
2.3 Key advantages of Mode Entry
related parameters within a unique module.
- Controls the target mode’s parameters and mode transition without CPU intervention (see Section 2.3.1: Transition control)
- Power modes managment centralaized (see Section 2.3.2: Modules/peripherals configuration)
- Provides a SAFE mode to manage HW failure (see Section 2.3.3: HW failure and error modes management)
2.3.1 Transition control
- 1st write: TARGET_MODE + KEY
- 2nd write: TARGET_MODE + INVERTED KEY Once the double writing is done, the complete transition could be triggered by following bits:
- S_MTRANS bit of Global Status Register (ME_GS) – S_MTRANS = 0 (Transition not active) – S_MTRANS = 1 (Transition ongoing)
- I_MTC bit of Interrupt Status Register (ME_IS) – I_MTC = 0 (No transition complete) – I_MTC = 1 (Transition complete) Note: Bit I_MTC is not set in case of tr ansition to low power modes (HALT / STOP)
2.3.2 Modules/peripher als configuration
Either modules or peripherals are managed by ME.
- Output Configuration For some modes it is possible to put the IO in power-down status (PDO), forcing outputs of pads to high impedance state or switching off the pads’ power sequence driver
- Main Voltage Regulator (MVREG) Configuration For some modes it is possible to switch-off the MVREG in order to minimize the consumption
- FLASHs Configuration For some modes it is possible to configure the code and data Flash in normal, low power and power down
- Clocks Configuration ME module is in charge of: – Main XOSC switching on/off – IRC fast switching on/off – FMPLL switching on/off – System Clock selecting Not all modules can be configured in each mode. Following a table that describes all the possible modules configurations for each mode:
Table 1. Module configuration (1)
- Current mode: Drun with system clock = IRC (default)
- Target mode: RUN0 mode with system clock = XOSC Steps
- Configuration of RUNO mode – ME_RUN0_MC.OSCON = 1 – ME_RUN0_MC.SYSCLK = XOSC
- Transition request – ME_MCTL = DRUN + KEY – ME_MCTL = DRUN + INVERTED KEY
- Waiting for the transition complete through the ME_IS.I_MTC bit
Figure 6. Mode transition example Table 2. Clock configuration (1)
- 8 Running registers (ME_RUN_PC[0..7]) to generate 8 different configuration in running modes
- 8 Low-Power registers (ME_LP_PC[0..7]) to generate 8 different configuration in low power modes
- One register for each peripheral (ME_PCTL[x]) that address one of the Running configuration and one of the Low-Power configuration Following is an example that describes how to clock gate/enable EMIOS peripheral: Mode Entry - example EMIOS0 Clock Gating
- Configure EMIOS in the following way – Active in DRUN, RUN0, STOP mode – Clock Gated in the others mode Steps
- Configuration of Running mode – ME_RUN_PC[1].DRUN = 1 – ME_RUN_PC[1].RUN0 = 1
- Configuration of Low Power mode – ME_LP_PC[2].STOP = 1
- Configuraion of EMIOS (peripheral number = 72) – ME_PTCL[72].RUN_CFG = 1 – ME_PTCL[72].LP_CFG = 2
Figure 7. Peripheral configuration example
2.3.3 HW failure and error modes management
ME Provides a SAFE mode to manage either HW failure or errors caused by incorrect mode transition configurations. HW failure management Device can manage some HW failure events to force SAFE mode transition instead of generating a reset. This is possible through RGM (Reset Generation Module), which, for examples, allows to configure following less-critical functional events:
- FMPLL failure
- FXOSC failure
- CMU clock frequency higher/lower than reference
- 4.5 V low-voltage detected
- code or data Flash fatal error So, if one of these happens, the system enters into a pre-defined SAFE configuration from which it may try to recover. It is also possible that SAFE transition is triggered by an interrupt through the ME. Following is an example that describes how crystal failure event can be managed: Example
- Current mode: DRUN with system clock = IRC (default)
- Target mode: RUN0 mode with system clock = XOSC
- XOSC failure event hapens Steps
- Configuration of RUN0 mode – ME_RUN0_MC.OSCON = 1 – ME_RUN0_MC.SYSCLK = XOSC
- Configuration of XOSC failure as SAFE transtition – ME_RGM_FERD.D_CMU_OLR = 1 – ME_RGM_FEAR.AR_CMU_OLR = 0
- Configuration of SAFE mode interrupt – ME_IM.M_SAFE = 1
- XOSC failure event hapens
- Software Transition request – ME_MCTL = RUN0 + KEY – ME_MCTL = RUN0 + INVERTED KEY
- SAFE mode transition forced and interrupt generated
Figure 8. HW failure example
- Invalid mode configuration: following rules should be respected in order to prevent error configuration event: – IRC should be ON if: sysclk = rc_clk or sysclk = rc_clk_div – XOSC should be ON if: sysclk = osc_clk or sysclk = osc_clk_div – PLL should be ON if: sysclk = pll_clk – Configuration "00" for the CFLAON and DFLAON bit fields should not be used – MVR must be ON if any of the following is active: PLL/CFLASH/DFLASH – System clock configurations marked as ’reserved’ may not be selected – Configuration "1111" for t he SYSCLK bit field is allowed only for STOP0 and TEST modes If one of the previous rule is violated, I_ICONF bit in the Interrupt Status register ME_IS is set
- Invalid mode transition Following cases should be avoided to complete the transition properly: – Mode requested when a transition is active (mode transition illegal) – Target mode not valid wit h respect to the current (mode request illegal) – Target mode is disabled in mode enable register (disable mode access) – Target mode doesn’t exist (non existing mode access) previous cases are signaled by ME_IMTS register.
2.4 Application cases
(RESET DRUN), transitions have either HW or SW aspects in the others cases.
2.4.1 Power-on reset phase (RESET DRUN)
Figure 9. Transition (HW start-up) RESET DRUN (execution from CFlash)
2.4.2 Application scenarios
running and low power modes.
- <target mode> configuration check While programming the mode configuration registers ME_<target mode>_MC, some rules must be respected. For example, if PLL is set to be the system clock in <target mode>, PLL should be turned on. Otherwise, the write operation is ignored and an invalid mode configuration event may be generated. Please refer to Error Management Chapter for detailed informations.
- <target mode> transition parameters check There are some conditions that make the transition request invalid. For example, if the target mode is not a valid mode with respect to current mode. In this case, an invalid mode transition event may be generated. Please refer to Error Management Chapter for detailed informations.
- <target mode> modules/peripherals switching on/off Once the transition is requested by sw, the HW is in charge of switching on/off all modules/peripherals. Now, if a module failure happens (i.e: XTAL or PLL lock failures) the transition stalls in an ongoing status. However, The failures can be managed via software. Please refer to Error Management Chapter for detailed informations. For this reason, in order to prevent to stuck the code waiting for transition completion, it could be better to set a timer, before entering in RUN0 mode, that, if expired, is able to signal every potential issue. Timeout calculation should be based on modules/peripherals start-up timing and, so, varies case by case. Scenario 1 (DRUN RUNx) This scenario is a typical application that starts from a default mode and transits to a full device performance user mode. Following is the configuration of each mode.
Figure 10. Node configuration
Figure 11. Transition step
Table 3. Loop divide ratio
0100000 Divide by 32
0100001 Divide by 33
0100010 Divide by 34
1011111 Divide by 95
1100000 Divide by 96
Table 4. Input divide ratio
0000 Divide by 1
0001 Divide by 2
0010 Divide by 3
1110 Divide by 15
Table 5. Output divide ratio
00 Divide by 2
01 Divide by 4
10 Divide by 8
11 Divide by 16
Table 6. SPC560B54/6x peripheral clock sources
- Request transition to RUN0 mode:
and the required target mode into the TARGET_MODE bit field. switches-on/off modules and peripherals without CPU intervention. the modules configured as expected. one of the new challenge in body. Figure 12. Scenario 2 - finite state machine
Figure 13. Scenario 2 - flow chart
1 HALT Mode
4 Request
6 HALT Mode
8 RUN0 Mode
- Periphs mode config HALT mode:
- Request transition to RUN0 mode:
Table 7. Peripherals clock source
switches-on/off modules and peripherals without CPU intervention. peripherals to switch-on, timeout could be considered equal to few clock cycles. maintained in the same status of the RUN0 mode. reduce average consumption while the application is still 100% functional.
- Transition HALT RUN0 mode:
certain time the activity in the vehicle. Figure 14. Scenario 3 - finite state machineHardware triggered transition
Figure 15. Scenario 3 - flow chart
1 STOP Mode
6 STOP Mode
For the HW steps, refer to Chapter : Common HW aspects. Now, see in details operation done for each phase: RUN0 mode: 1. Mode config in STOP: ME_STOP_MC.CFLAON = 1 (code Flash in Power-Down) ME_STOP_MC.DFLAON = 2 (data Flash in Low Power mode) In this way, at STOP exiting, Flash startup from Power-Down to Normal mode takes few usecs ME_ STOP_MC.XOSC0ON = 1 (turn-on the XTAL) The XTAL is maintained on in STOP in order to clock CAN protocol handler: in this way PLL jitter issues are avoided ME_ STOP_MC.SYSCLK = 0 (set FIRC as device system clock) 2. Periphs mode config STOP mode: ME_RUN_LP0.STOP = 1 (activate low power peripheral configuration ’0’ in STOP) ME_PCTL[16].LP_CFG = 0 to select the low power peripheral configuration ’0’ for FlexCAN0 identified by offset = 16 (refer to figure x) 3. Timer config: See Step 5 (RUN0 HALT mode) 4. Request transition to RUN0 mode: in case of RUN0 STOP transition, these two register writing should be done: ME.MCTL.R = 0xA0005AF0 ME.MCTL.R = 0xA000A50F 5. RUN0 STOP mode: Once a valid mode transition request is detected, the transition starts. Here, device switches-on/off modules and peripherals without CPU intervention. It is possible to check for transition completion through mode Transition Status bit: while (ME.GS.MTRANS != 0) //transition ongoing ... //transition completed ... in order to prevent code stucking waiting for transition completion, it could be better to check transition timing through a timer. As, in this case, as there aren’t any slow-start- up peripherals to switch-on, timeout could be considered equal to few clock cycles. 6. STOP mode: At the end of the transition, device enters in STOP mode with core switched-off, FlexCAN0 switched-on and CFLASH in Power Down. All others peripherals are maintained in the same status of the RUN0 mode. At this point, if a FlexCAN0 interrupt event is generated, the device, automatically, starts the transition to go back to the previous RUN0 7. transition STOP RUN0 mode: During the STOP RUN0 transition, the device automatically restores the peripherals/modules as they were configured before entering in STOP . So, core is already on and CFLASH comes back to Normal mode
(for example ADC acquisition). Figure 16. Scenario 4 - finite state machine
Figure 17. Scenario 4 - flow chart
For the HW steps, refer to Section : Common HW aspects. Now see in details the operation done for each phase: RUN0 mode: 1. Mode config in STDBY: STANDBY mode, by default has already following configuration: – CFLASH/DFLASH in Power Down –X T A L O F F – Sysclk OFF So, the only sw configurations to perform are: ME_ STANDBY_MC.FIRCON = 0 (turn-off the FIRC) CGM_ LPRC.LPRCON_STDBY = 1 (turn-on the LPRC in STANDBY) Moreover, it needs that all peripherals are clock-gated, otherwise, STANDBY mode is not entered properly, so: ME_ RUN_LPx.STANDBY = 0 (all low power peripheral configuration registers used should have STANDBY disabled) 2. STDBY Boot config: RGM_STDBY .BOOT_FROM_BKP_RAM = 1 (boot from SRAM on STANDBY exit) ME_DRUN_MC.CFLAON = 1 (code Flash in Power-Down) PCU_PCONF2.STDBY0 = 0 (SRAM 24K powered-off) with these settings, after exiting from STANDBY , device enters in DRUN booting from SRAM (8K backup) with CFLASH in Power-Down, minimizing consumption 3. API config: This step should configure the API to generate a periodic wakeup to exit device from STANDBY 4. Request transition to RUN0 mode: in case of RUN0 STANDBY transition, these two register writing should be done: ME.MCTL.R = 0xD0005AF0 ME.MCTL.R = 0xD000A50F 5. RUN0 STANDBY mode: Once a valid mode transition request is detected, the transition starts. Here, device switchs-off core and all the modules/peripherals that belong to Power-Domain #1. Only Power-Domain #2 is maintained on.
Figure 18. Power domain
- Transition STANDBY RESET DRUN mode:
CFLASH/DFLASH in Power Down once in DRUN. Generation Module(RGM), Voltage regulator. represents a power switching device. For the sake of simplicity this has been drawn as a mechanical switch.
Figure 19. STANDBY transition
- 8 - DRUN mode: At the end of the transition, device enters in DRUN mode fetching the code from the first SRAM location (0x40000000). RUNo STANBY0 mode set due to reset being asserted to power domain RUN0 STANBY0 DRUN new mode requested by ME PSTAT.PDI voltage in power domain #1 wakeup request current mode power-up state power- down phase power-down state power-up phase power-up state
3 Consumption tables
configurations. These values should be based on Bol1.5M cut2.0 measurements.
3.1 Running mode
- Code: continuous data transfer from Flash to RAM
- fsys = system clock (MHz)
- code executing from Flash
- all peripherals gated Where PDO = Power Domain 0 In this way, it is possible to calculate the total consumption related to a specific configuration easily. As an example, consider following configuration at fsys = 16 MHz:
Table 8. RUN0 mode consumption table
3.2 Low Power modes
3.2.1 HALT consumption
Table 9. RUN0 mode consumption example Table 10. HALT mode consumption table
- Core/Platform + Power Domain 0 (always On) consumption
- Consumption of Power Domain 1 that depends on t he system clock (divided or not) provided to the
3.2.2 STOP consumption
Table 11. HALT mode consumption example
- Core/Platform + Power Domain 0 (always On) consumption
- Consumption of Power Domain 1 that depends on t he system clock (divided or not) provided to the
Table 12. STOP mode consumption table
- Core/Platform + Power Domain 0 (always on consumption
- Consumption of Power Domain 1 that depends on t he system clock (divided or not) provided to the
Table 13. STOP mode consumption example
- Core/Platform + Power Domain 0 (always on consumption
3.2.3 STANDBY consumption
On the other hand, maximum consumption (FIRC,SIRC,SRAM-24K on) is 314.8 µA.
3.3 Peripherals
either dynamic or static consumption.
- Consumption of Power Domain 1 that depends on t he system clock (divided or not) provided to the
Table 14. STANDBY mode consumption table
- Core/Platform + Power Domain 0 (always on consumption
- Consumption of Power Domain 1 that depends on t he system clock (divided or not) provided to the
3.4 Consumption example
- Fperiph = PLL at 32 MHz
- Fcan = XTAL at 8 MHz (to avoid PLL glitches) Each peripheral is showed in the following table:
Table 15. Peripherals consumption table
500 Kbps Total (static + dynamic)
Table 16. Peripherals consumption example
4 Revision history
Table 17. Document revision history 17-Nov-2010 1 Initial release. 25-Sep-2013 2 Updated Disclaimer.