Idle Mode Hangs

[barak]

Posted on April 15, 2008 at 05:47

Idle Mode Hangs

[barak]

Posted on May 17, 2011 at 09:48

Hi,

I am using Idle and Sleep Mode in my Application. I noticed that some times the CPU does not exit IDLE MODE. it takes a while to reproduce. in order to be curtain that I am in IDLE mode I do as folow. a.measure the power consumption. b.togle one of ther outputs when i enter and exit the Idle function. c.and also toggle another output in tyhe IRQHandler Asmembly code to make sure i it was not caused of an interrupt. all these 3 parametters point out that I Am realy hanged in Idle Mode. the coder looks like this: __ramfunc void Idle(void) { WIU->PR = 0XFFFFFFFF; //Clear all flag SCU->PWRMNG |= 0x1;/*Enter Idle mode*/ asm( ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ''NOP\n'' ); return; } i Am using 6.25CLK with 25Mhz OSC. i know i need only 3 nops but it never hurts to have some more. there are 4 interrupt enabled and working during the regular operation. 1 timer. 2 Uarts. 1 DMA. does any one have any idea.

[m_j_butcher]

Posted on May 17, 2011 at 09:48

Hi

This is something which I am also interested in and am presently having about the same results. I am using an FA revison chip which shouldn't need all work arounds. I want the interrupts to be activated AFTER the chip is set to idle mode [the operating system checks for any flags indicting that a task needs to run with disabled interrupts and only when nothing is pending will switch to idle mode and enable interrupts to wake it when needed]. There is a 10ms system TICK which is waking each interval for a few us. Before switching to idle mode I set the idle clock gating to match the main clock gating (to be sure for first tests). The current consumption at 96MHz (measured at the input to a DC/DC converter so not the processor current - there are some other thing sbeing powered too) drops from 105mA to 60mA when the IDLE support is activated. When only the timer tick is running it seems stable. I am not operating the mode change in RAM since I have an FA revision where it shouldn't be necessary. It should take about 96 cycles (96MHz PLL and 12MHz crystal) to enter the IDLE mode. So I use these cycles to enable the interrupts and run a short wait loop. The absolute length of the wait loops seems to make no real difference. When I use the serial interface it smoetimes hangs in the IDLE state. The TICK is synchronised to the IDLE mode change but the serial interrupts are asynchronous and my present feeling is that there is a problem when an interrupt is served when the device is switching to the idle mode. If, during the several cycles between the idle mode command and the switch to idle mode, and interrupt arrives I presume that the interrupt vector will be taken and the interrupt service routine starts. This masks the interrupts and so when the idle mode is entered it can never be woken by a further interrupt. Does any one know more or have a method of doing it properly?? Regards Mark

http://www.uTasker.com

[16-32micros]

Posted on May 17, 2011 at 09:48

Dear mjbcswitzerland, baradkon,

Could you please send me your software to debug it on my FA board in order to identify the root cause of your issue, Thank in advance. Normally we should not have any issue with IDLE mode ( some issues was been identified in F versions , but was fixed on FA :This is described in FA erratasheet) Regards , STOne-32

[m_j_butcher]

Posted on May 17, 2011 at 09:48

Hi STOne-32

Do you have the STR9_DONGLE? I have a complete demo project which runs on that

http://www.utasker.com/forum/index.php?topic=122.0

which probably makes most sense. It has an optional idle task which switches the mode when there are no task waiting to work. I will activate the IDLE task and test it on the STR9_DONGLE to ensure that the problem is reproducable using normal Ethernet activity. I can also send a project for the Raisonance board or the IAR STR912-SK (but my RAisonance one doesn't have an FA revision on it so I can't test the IDLE mode using it... the IAR board does...). What is your preference? regards Mark

[barak]

Posted on May 17, 2011 at 09:48

Hi Mark ST0ne-32,

I simplified my system to test this issue and worked exactly as you mark described . I Used 1 timer with 10ms ticks and sending data using serial port. Well, the system hangs in IDLE. This is very easy to reproduce. I sent ST’s team my project just a few minutes ago. This reconfirms that we are having the same problem. B.R

[m_j_butcher]

Posted on May 17, 2011 at 09:48

Hi

I also set up a demo project for the STR9-DONGLE (running at 48MHz rather than 96MHz as the previous project I tested with the IDLE mode). But I have found that with the same IDLE switching code it hangs as soon as the idle mode is entered. The strange thing is that there is no current consumption reduction when the IDLE mode is set. Therefore I am also trying to understand what the difference is (this time on the STR912FA with active Ethernet) and will wait for any results of the other investigation... Regards Mark

[barak]

Posted on May 17, 2011 at 09:48

Hi Mark,

I am still in the Dark regarding this issue. Any new findings at your side? B.R

[m_j_butcher]

Posted on May 17, 2011 at 09:48

Hi B.R.

I am still waiting to hear feedback from your code analysis so have not done anything else in the mean time. I have however used the same technique using ATMEL SAM7 and Freescale Coldfire processors, so it may be interesting to compare the solutions used there with the STR9 technique: All these devices support an IDLE mode in which the CPU clock is essentially stopped. The peripherals can continue to operate and any interrupt immediately causes the CPU to wake up again. This reduces power consumption since the CPU doesn't have to run when it has nothing to do and system reaction time and performace is not degraded since there is no start up delay involved. The Freescale Coldfire chip uses the STOP instruction. This instruction is used as follows: stop #0x2000 , where 0x2000 is the value written to the status register. This works very well since it is possible to have interrupts masked up to the stop instruction and set a new interrupt mask level (the example opens up all interrupts) as the instruction is executed, for peripherals to wake us out of the idle mode. The ATMEL SAM7X uses a clock disable instruction: PMC_SCDR = PROCESSOR_CLK_ENABLE; This removes the clock to the CPU. Even if the main interrupt is masked, any interrupt source can wake the processor again, even if it doesn't cause a real interrupt. This is useful since it allows the following code to successfully operate: PMC_SCDR = PROCESSOR_CLK_ENABLE; // waits in IDLE mode until an interrupt source wakes enable_interrupts(); // enable interrupts, causing interrupt servicing to take place The STR device uses a similar technique of disabling clocks to the CPU, whereby perpheral clocks can continue to operate. However it is not absolutely clear whether the main processor interrupt has to be enabled or whether individual interrupt sources are capable of waking the processor, even if the main mask is set. I have tried the following: volatile int iLoop = ((MASTER_CLOCK / CRYSTAL_FREQ)*12); // overkill to be safe SCU_MGR0 = SCU_PCGR0; // set idle mode mask to same setting as main clock mask SCU_MGR1 = SCU_PCGR1; SCU_PWRMNG = PWR_MODE_IDLE; // disable the processor clock to enter idle mode // the processor runs for about 12 oscillator cycles before entering the low power mode // the number of instructions that can be executed is the (master clock / oscillator) // for 96MHz operation and 12MHz crystal this would be about 96 instructions while (--iLoop != 0) {} // ensure the idle mode is entered before enabling interrupts uEnable_Interrupt(); // allow servicing of interrupt which has woken us Thie works for a short time before the processor hangs (when sending data over the UART). Then I increase the loop count value by factor 10. Now it ALWAYS hangs immediately. My conclusion is that the processor is taking more clock cycles to go to the idle state than expected. It is probably going to this state AFTER the main interrupt has been enabled (suggesting that the enable is absolutely necessary). With a longer loop, the enable interrupt routine is never reached so it can never wake up. My feeling is still that there is a risk of an interrupt arriving between performing the enable interrupt and the processor going to IDLE mode. In this case it sleeps in the interrupt routine when the interrupt mask has been set again and so can never leave this mode again. I don't see a safe mechanism for moving from the interrupt disabled state to the IDLE state with interrupts enabled - this is irrespective of the fact that the IDLE mode takes a certain number of clock cycles to enter into or not. I am hoping that I have made an error somewhere and that it is possible to successfully use the IDLE mode. The 96MHz operation is useful for encryption applications where processing delays must be kept to a minimum, but its increased current consumption when the clock is always at this speed is detrimental. The IDLE mode technique would be the perfect solution. I will wait until ST posts feedback. Regards Mark

[mark9]

Posted on May 17, 2011 at 09:48

I'm waiting for an answer as well... I had severe problems with the F version, and less issues with the FA version, but it never worked reliably for me. I've got posts on this issue on a different thread, but its been so long, I've forgotten !

-Mark Lakata