NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
OMAP35x and AM/DM37x Debug Steps for Idle Entry
The first step is to get the MPU to go into idle. You can check the PM_PREPWSTST_MPU.LASTPOWERSTATEENTERED bit field. This bit field will show what the MPU power state was for the previous idle state. This register can be cleared so that you can keep track of the MPU idle states. The MPU power domain must be active in order to clear it and when cleared it gets set to the “on” state.
In order for the MPU to go into idle there cannot be a pending interrupt or a pending wake up event. The most common wake up event is a wake up dependency with another domain.
The following steps can be used when debugging the MPU power domain not going into idle. It is recommended to dump the necessary registers prior to the wait for interrupt instruction when you want the MPU to go into retention or to add a long loop at this same location and then connect with a debugger.
- Verify all interrupts are cleared. Check the INTC registers to see what IRQ is pending. Be sure to service this IRQ by clearing the IRQSTATUS in the module’s registers.
- Check the PM_WKDEP_MPU register to make sure that only the domains desired are enabled. In most cases only the WKUP domain is enabled.
When the MPU is in idle (wait for interrupt instruction) then the MPU will need an interrupt and a wake up event to pull it out of idle. The wake up event is needed so that the PRCM will turn back on the clocks and power. The interrupt is needed so that the MPU will exit the wait for interrupt (WFI) instruction. If a wake up event occurs with no associated interrupt then the clocks and power will turn back on but the MPU will remain sitting in the WFI instruction.
The CORE power domain is more difficult to get into idle due to the number of peripherals. Similar to debugging the MPU, it is recommended to dump the necessary registers prior to the wait for interrupt instruction when you want the CORE to go into idle or to add a long loop at this same location and then connect with a debugger. You can check the PM_PREPWSTST_CORE.LASTPOWERSTATEENTERED bit field. This bit field will show what the CORE power state was during the previous idle state. This register can be cleared so that you can keep track of the CORE idle states. The CORE power domain must be active in order to clear it and when cleared it gets set to the “on” state. The following steps should be taken when debugging the CORE power domain not entering retention.
- Make sure all pending wake up events have been serviced by clearing the PM_WKST registers.
- Check the CM_IDLEST registers – this may be a quick indicator to let you know which interface clock is remaining on. Even though the CM_IDLEST registers show all peripherals inaccessible, it does not mean they are all in idle. But if one of the peripherals indicates it is accessible then it is definitely not in idle.
- Check the CM_IDLEST_CKGEN. All clocks except the DPLL3 should be in bypass. In some cases the 96MHz is not in bypass mode. This will indicate that a user of this clock is not idled. This will help narrow down which driver to look at since only serial interfaces use this clock. Note that the DPLL3 status will show as being locked because when you dumped this code the hardware has not placed the DPLL3 into bypass yet.
- If all of the previous checks did not fix the issue then the next thing to do is to look into each of the drivers that are being used and check the SYSCONFIG register within the module’s register set. You want to make sure the IDLEMODE is not set to “no idle”. It can be set to “smart idle” or “force idle”.
Checklist for CORE Power Domain Idle Entry
The CORE power domain on OMAP3 has 4 CORE clock domains:
Each CORE clock domain needs to enter idle before the CORE power domain can enter any of the low power states.
Each clock domain has multiple dependencies with surrounding domains. It is required that all domains with hardware sleep dependencies are idled before the CORE power down transition can happen. A domain is considered idled when the initiators are mute (in standby) and the targets are idled. Initiators are masters and can generate traffic and targets are slaves and cannot generate traffic.
The following table shows the dependent domains for the CORE_L3 and CORE_L4 and whether the domain contains initiators or targets:
The following is a checklist for items that will prevent idle entry for the CORE power domain.
- The pin mux for the D2D Idle Ack and D2D MStandby must be pulled high. Set the CONTROL_PADCONF_SAD2D_IDLEACK and CONTROL_PADCONF_SAD2D_MSTDBY to have a pull up.
- In later silicon versions (ES3.0 and up) the D2D interface clock is enabled after reset. This clock must be disabled. This clock is located in bit 3 in the CM_ICLKEN1_CORE register.
- If a debugger is being used it is best practice to disconnect and remove the JTAG connection.
- The wake up status for the CORE, PER and WKUP domains must be cleared (PM_WKST1_CORE, PM_WKST3_CORE, PW_WKST_PER and PM_WKST_WKUP).
- For a module to generate a wake up, most modules require enabling the wake up capability in the PRCM registers (PM_WKEN) and also in the modules registers. If the wake up is enabled, then the IRQ status for this module must be cleared in the MPU INTC registers and also in the module’s registers. For example, the GPTIMER1_IRQSTATUS must be cleared and then the MPU INTC must be serviced and cleared for the GPTIMER1 IRQ.
Note that GPIO modules have two IRQ status registers (IRQSTATUS1 and IRQSTATUS2) and both status registers must be cleared.
- Check the idle status for the modules to verify that all modules are not accessible (CM_IDLEST). This ensures the module is not accessible, but does not guarantee the module is idled.
- Disable the interface clock by clearing ICLK (CM_ICLKEN) or leave the ICLK enabled and at the same time enabling the AUTOIDLE feature in the PRCM (CM_AUTOIDLE).
- Manually disable all functional clocks (CM_FCLKEN).
- Caution should be made in that disabling a FCLK may not idle the module.
- In all of the module’s SYSCONFIG registers, ensure that the CLOCKACTIVITY bit field is set to 0x0 to allow the interface and functional clocks to be gated. This is not necessary but will help with power savings.
- For targets, in the module’s SYSCONFIG register, ensure the SIDLEMODE is set to FORCE_IDLE or SMART_IDLE and not set to NO_IDLE. SMART_IDLE is recommended.
- For initiators, in the module’s SYSCONFIG register, ensure that MIDLEMODE is set to SMART_STANDBY or FORCE_STANDBY and not set to NO_STANDBY. SMART_STANDBY is recommended.
- If the SYS_BOOT pins are configured for UART3 peripheral boot then the boot ROM sets the UART3_SYSCONFIG(SYSC_REG).IDLEMODE to NO_IDLE. This will need to be changed to SMART_IDLE or FORCE_IDLE.
- If the SYS_BOOT pins are configured for MMC1 peripheral boot then the boot ROM sets the MMCHS1_SYSCONFIG.SIDLEMODE to NO_IDLE. This will need to be changed to FORCE_IDLE.
- If the SYS_BOOT pins are configured for USB peripheral boot then the boot ROM sets the OTG_SYSCONFIG.SIDLEMODE to NO_IDLE. This will need to be changed to FORCE_IDLE.
- Often overlooked is the CONTROL_SYSCONFIG. Ensure IDLEMODE is set to SMART_IDLE.
- All DPLLs must be set up for AUTOIDLE (CM_AUTOIDLE).
- All DMA transfers must be completed and stopped.
- All pending transactions to the SDRAM must be stopped. For example a DMA moving data to or from the SDRAM must be completed.
- The SDRAM must be set up to allow self refresh on idle request. This is done by setting the SRFRONIDLEREQ bit in the SDRC_POWER_REG register.
- Enable Hardware supervised transition in CM_CLKSTCTRL registers for all domains – don’t forget about the EMU domain. The D2D must be set for hardware supervised transition by setting bits 4 and 5 in the CM_CLKSTCTRL_CORE register.
- The POWERSTATE bit field in the PM_PWSTCTRL registers must be set for the power state desired.
- The WFI instruction issued by the ARM is recommended to be executed from I-CACHE or Internal SRAM. Concern should be made when executing from I-CACHE that the instruction execution does not go back to SDRAM before the SDRAM is accessible. The WFI instruction may be executed from other memory locations but this has not been thoroughly tested.