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 Mark,Lakata,

I have just recieved a confirmation from ST's Team that they were able to reproduce the Idle Hanging and they are investigating the problem. I am waiting for More info from ST. i will keep you updated as well when I get more information from them. B.R

[m_j_butcher]

Posted on May 17, 2011 at 09:48

Hi All

Just so this thread doesn't die... Is there any more news that anyone has? The equipment which we are prototyping replaces an older product which runs at 35'000 locations (they tend not to be switched off). The new one consumes more power due to the fact that it is more processing intensive (when it has to the real work) and so 96MHz opertion is required. If I could use the idle mode I could save about 0,3W for each device (approx. based on tests), which makes about 10.5kW saving assuming it will be produced in the same quantities. It may be only a drop in the ocean and will win no Nobel Prizes, but it is worth investing a bit of development effort to optimise a bit. Regards Mark

http://www.uTasker.com

[ This message was edited by: mjbcswitzerland on 14-12-2007 17:54 ]

[barak]

Posted on May 17, 2011 at 09:48

Hi All,

12 days has passed from the last time I have heard from ST directly when they Said they were able to reproduce the problem. But We had received conformation from ST Representatives over here that it is a real BUG and it is not clear yet what ST is going to do about it. On our side we need to know if ST is planning to fix these issue or on the other hand are they going to release this chip with 2 major problems in the low Power modes. 1. SLEEP mode Hanging. 2. IDLE mode Hanging. I really hope that they are planning to come out with a new revision fixing these issues. B.R

[16-32micros]

Posted on May 17, 2011 at 09:48

Dear all,

A new Erratasheet update for STR91xFA will be available soon on ST web pages and among the updates : Two Limitations in Low Power Modes ( one for Sleep Mode and teh other in IDLE) have been identified and here the summary : 1) Code execution after setting the Sleep or Idle mode bit ------------------------------------------------------------ Once the Idle or Sleep mode are entered by writing the PWR_MODE[2:0] bits in the SCU_PWRMNG register, it takes about 12fOSC cycles for the device to stop the execution. In addition, if a wake-up event or an interrupt (external or internal coming from peripherals) occurs during this period while entering Idle, the internal low power state machine is frozen and the STR91xFA hangs. In this case, only a reset event can wake up the device. Workarounds ----------- In order to avoid executing any valid instructions after setting the Idle or Sleep bit and before entering the mode, it is mandatory to execute a certain number of dummy instructions after setting the SCU_PWRMNG register. The number of dummy instructions to be executed is given the following formula: No_dummy_instr fCPUCLK = ( �?� fOSC)× 12 where fCPUCLK is the CPU core clock frequency and fOSC is the oscillator frequency. The worst scenario is obtained when the core works from the PLL maximum frequency (96 MHz) with an 4 MHz crystal or oscillator connected to the X1_CPU input. In this case 288 dummy instructions are needed. Note: If (fCPUCLK/fOSC) is less than 1, the number of dummy instruction is always 3. Random external/internal wake-up events or interrupts may freeze the STR91xFA when occurring during the execution of these dummy instructions. In this case, only a reset event can wake up the CPU. This limitation will not be fixed in future silicon revisions 2) Time required to enter Sleep mode After the mode bit is set in the SCU_PWRMNG register, the power management unit requires a period of time (tSLEEP) to switch off all CPU and peripheral clocks safely before entering Sleep mode. A very slow peripheral clock results in a long switch off time. The tSLEEP time required to enter Sleep mode depends on the oscillator frequency, on the slowest peripheral clock frequency, and on the CPU clock frequency. If a wake-up event occurs during tSLEEP, it is ignored and the STR91xFA does not exit from Sleep mode. tSLEEP is given by the following formula: tSLEEP = 17 × t_OSC+14 × t_Slowest_IP_CLK+6×t_CPUCLK where t_OSC is the oscillator frequency, t_Slowest_IP_CLK the slowest peripheral clock frequency, and t_CPUCLK the CPU clock frequency. Workarounds ------------- To prevent random external wake-up events from occurring while the device is entering Sleep mode (during tSLEEP), the maximum time required by the application to enter Sleep mode must be taken into account. This limitation will not be fixed in future silicon revisions. Regards, STOne-32

[mark9]

Posted on May 17, 2011 at 09:48

Wait second ... idle and sleep don't work, AND ST is no longer supporting this chip?

Mark Butcher, based on the errata's use of the word ''about'', I assume that you need to some how synchronize with the Oscillator clock edge and not the PLL clock edge, so that it takes 11/fOSC < t <= 12/fOSC for idle mode to start. I don't know how to sync with the Oscillator clock unless you are not using the PLL, so there will be a random element in figuring at exact time to re-enable interrupts just before it goes to sleep. Oh, wait, that is the answer. Change speeds to turn off the PLL, so the clocks are synchronized. ie turn off PLL and run at oscillator speed turn off interrupts sleep bit on 1 NOP 2 NOP 3 interrupts on ?

[m_j_butcher]

Posted on May 17, 2011 at 09:48

Hi STOne-32

Assuming that I can calculate the exact number of instructions which are executed between executing the idle instruction and the device entering the idle mode, would it be possible to do the following? 1. Disable interrupts 2. Command IDLE mode 3. Execute dummy instructions (padding) 4. Enable interrupts (the instruction coincides with the last clock before IDLE mode) 4. The device is now in IDLE mode with enabled interrupts and so will be woken on any enabled interrupt event Or is it not possible to garantie the transfer between disabled interrupts during IDLE mode transition and entry to IDLE mode with enabled interrupts? As I understand it, the IDLE /SLEEP modes can otherwise not be used if there are any interrupts which may arrive during this phase (eg. UART, Ethernet etc, where the device itself can not control when they may arrive). This would leave IDLE/SLEEP modes only for use in systems which do not actually interact with the outside world - or perform everything by polling based on a Timer tick synchronised to the IDLE sequence. Are there any code suggestions for the workaround? Regards Mark Butcher

http://www.uTasker.com

[amira1]

Posted on May 17, 2011 at 09:48

Hello all,

Please refer to the new errata sheet available on this link: http://www.st.com/stonline/products/literature/es/12944.pdf There are a detailed description of this problem and some proposed workarounds. Best regards, mirou.