STM32F10x entering standby mode fails occasionally

[sandeshm]

Posted on October 28, 2016 at 02:11

We use PWR_EnterSTANDBYMode library function to enter the standby mode. I have added line to enable WKUP pin. The STM32 enters standby mode most of times. But, sometimes(once in 25 or so times), it just reaches the printf statement and prints the message on debug port. Any ideas as to what might be causing this?

I do not de-initialize the UART, I2C, ADC or SPI modules before calling enter_standby_mode function. should I be disabling the clock to these peripherals? //enter standby modevoid enter_standby_mode(void){        PWR_EnterSTANDBYMode();        printf(''ENTERING STANDBY MODE WENT WRONG!!!\n\r''); }/**  * @brief  Enters STANDBY mode.  * @param  None  * @retval None  */void PWR_EnterSTANDBYMode(void){  /* Clear Wake-up flag */  PWR->CR |= PWR_CR_CWUF;  /* Select STANDBY mode */  PWR->CR |= PWR_CR_PDDS;  /* enable WKUP pin - Added by Sandesh : 15/6/2016*/  PWR->CSR |= PWR_CSR_EWUP;    /* Set SLEEPDEEP bit of Cortex System Control Register */  SCB->SCR |= SCB_SCR_SLEEPDEEP;/* This option is used to ensure that store operations are completed */&sharpif defined ( __CC_ARM   )  __force_stores();&sharpendif  /* Request Wait For Interrupt */  __WFI();} #stm32f10x #standbymode

[Tesla DeLorean]

Posted on October 28, 2016 at 04:00

What tool chain are you building with?

Is it possible that you get an interrupt at the WFI prior to the write buffers emptying?

[Walid FTITI_O]

Posted on October 28, 2016 at 10:23

Himukartihal.sandesh,

To avoid any possible problem even coming from the compiler optimization for code, try to apply the following : 1.Disable wakeup source 2.Clear wakeup flag 3.Enable wakeup source 4.Enter standby mode In your case , it would be like the following

/* Disable WKUP pin */
PWR->CSR &= ~PWR_CSR_EWUP; 
/* Clear Wake-up flag */
PWR->CR |= PWR_CR_CWUF;
/* Clear StandBy flag */
PWR_ClearFlag(PWR_FLAG_SB);
/* enable WKUP pin */
PWR->CSR |= PWR_CSR_EWUP; 
/* Enter standby mode */

/* Select STANDBY mode */
PWR->CR |= PWR_CR_PDDS;
/* Set SLEEPDEEP bit of Cortex System Control Register */
SCB->SCR |= SCB_SCR_SLEEPDEEP;
/* This option is used to ensure that store operations are completed */
#if defined ( __CC_ARM )
__force_stores();
#endif
/* Request Wait For Interrupt */
__WFI();

-Hannibal-

[sandeshm]

Posted on November 17, 2016 at 12:07

Hi Hannibal,

Thanks for your recommendation. I did make the changes you suggested and ran the code for few days. But, I still see the problem occurring occasionally. Should I de-initialize all modules like UART, I2C, SPI etc before entering the standby mode?

[Tim1]

Did you ever resolve this issue? If so, what did you do? Thank you in advance.

[Tesla DeLorean]

This thread is from 2 years ago, the forum has transitioned since then and posters may not be alerted to new posts.

The F1 is going to be very sensitive to the wakeup source states, I think these are OR'd together, and if any are set before going into STANDBY it's not going to come back out. Perhaps look at some of the newer lower power devices, and those which aren't 10+ years old, and some of the quirks have been addressed on.

[Tim1]

Thanks for your help. Have you encountered any issues with the STM32L series processors sometimes (1 out of 1000 times) not entering standby mode when requested?

[Tesla DeLorean]

L1 or L4(+) ?

I think one of the recurrent issues is with interrupts, make sure the sequence isn't caught mid process with a SysTick, TIM, RTC or other interruption.

If you call it from a while(1) does it repeatedly fail in these circumstances?

With or without debugger attached?

[Tim1]

We are using a STM32L476RGT6 running mbed. If we call the sleep function from a while(1) it usually works fine, but sometimes loops forever (or until the watchdog trips). This behavior only happens 0.1% of the time and happens without the debugger attached. Normally it goes to standby as expected and is later woken up by an RTC interrupt.

[Antypas.Peter]

I have just seen this happen on an STM32F469AI as well. What's interesting is that the code stopped executing as expected, but the core never entered the correct power state. It just kept drawing normal, run-mode level of current, and then failed to wake up with a pulse at PA0. It had to be reset.

My solution for this will be an external watchdog.