Leaving Standby by WakeUp pin and RTC Alarm

kris2399 · ‎2012-02-17

Posted on February 17, 2012 at 17:37

We use a strategy to wake up the STM32F103 from standby mode by means of the wakeup pin and/or from the RTC alarm. In our implementation it appears that the wakeup from the RTC alarm does occur when the wakeup pin is in a high state during standby. When the wakeup pin is in a low state this functions perfectly. Is it possible to have a wakeup from standby with the wakeup pin enabled and in a high state during standby? What are the necessary conditions to achieve this?

#stm32l151-standby-wakeup #rtc-standby-wakeup #wakeyp #rtc-alarm #standby

paulburke9 · ‎2012-10-10

Posted on October 10, 2012 at 13:31 The same problem happens with the F If the WakeUp pin is low on entering Standby mode, all is well; the first of RTC Alarm or WakeUp pin wakes the perocessor up. If the WakeUp pin is high when Standby is entered, the device disappears into dark night, until an external reset, unless the WakeUp pin is set low before the RTC alarm times out. My code:

PWR_FlashPowerDownCmd(ENABLE); 
ConfigRTCWakeup(u32Temp); 
PWR_WakeUpPinCmd(ENABLE); /* Enable wake from WKUP pin*/ 
EXTI->PR = 0x007FFFFF; // Clear any pending EXTI interrupts 
PWR->CR |= PWR_CR_CWUF; // In case the pin was high already 
for(t=0;t<200; t++) // This delay doesn't fix it 
; 
PWR_EnterSTANDBYMode();

Any ideas please? Paul Burke

pirow · ‎2012-10-24

Posted on October 24, 2012 at 18:04

pirow · ‎2012-10-29

Posted on October 29, 2012 at 11:21

I can confirm that the same happens on the F407. Same problem: when the wake-up line is asserted going to standby, the STM32 then requires a power cycle before coming back to life.

Anybody aware of a workaround or is this a silicon bug?

Sorry, previous post had some formatting errors...

Amel NASRI · ‎2013-02-25

Posted on February 25, 2013 at 11:23

Hi all,

For F1, this is the expected result as it is aligned with the wakeup logic explained in the reference manual (RM0008).

In fact, the MCU exists the Standby mode when a rising edge is detected on the WKUP pin or the RTC alarm. If the WKUP pin is high during the Standby mode, it will not be possible to detect the rising edge.

This is not a bug.

With F2 and F4, there is a new implementation that adds a wakeup event if the WKUP pin is already high (see RM0090 and RM0033). But this shouldn’t lead to the fact that MCU remains in standby mode as you described previously. I need to re-check this and I’ll go back to you with farmer details.

Best Regards,

ST.MCU

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Amel NASRI · ‎2013-02-25

Posted on February 25, 2013 at 11:36

@Pirow: I need more details on your use-case: is it similar to Paul's one? do you mean that only the external reset brings the MCU to run mode?

Thanks,

ST.MCU

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

brianshankland9 · ‎2013-03-04

Posted on March 04, 2013 at 15:17

Hello, I'm seeing a similar issue with the STM32L151ZD part.

I use both PA0 and PE6 for external wakeups from Standby Mode, but if either one of these is high during the configuration of the wakeup and entering standby, then the device will not wakeup if either pin is subsequently toggles low to high, nor dies any of the RTC events such as Alarm or periodic wakeup.

The only way to get the board to start is from a hard reset or by letting the watchdog expire.

I understand that if the external line is held high then it can never see that interrupt, but I would have thought if it later went low and then high again it should, else it is always going to be a race state for any asynchronous interrupt when you try to go into Standby Mode.

brianshankland9 · ‎2013-03-04

Posted on March 04, 2013 at 15:25

Just to add if anyone from ST needs more details then I'm happy to supply or try out any tests needed to rectify this.

Amel NASRI · ‎2013-03-05

Posted on March 05, 2013 at 09:36

Hi Brian,

Did you tried to disable the IWDG? Do you get the same result?

Best Regards,

ST.MCU

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

brianshankland9 · ‎2013-03-05

Posted on March 05, 2013 at 10:14

Hi, The problem existed before I had enabled the IWDG. We had hoped to avoid using the watchdog as our sleep periods are around 1 minute and the 28 seconds adds at least one extra

wakeup per minute.

I'm hoping to get some time this week to go back to basics and build a cut down project based on one of the peripheral library examples that I can use to experiment as the full project I have now is too large to share.

One test result I saw yesterday that I want to confirm with this is as follows.

I hold PE6 (WKUP3) high while the firmware does its shutdown process and had a pulse stream going into PA0 (WKUP1). While WKUP3 was held high this blocked WKUP1 and the RTC events, but as soon as I let WKUP3 go low I got a wakeup event from WKUP1.

I had previously thought that I had to wait until the next IWDG to fire before the problem cleared, and I had just added in a call to disable all IRQs prior to enabling the wakeup pins so need to check if this is the reason for the change, or if it was just a fluke.

I'm sure that if there was a silicon problem with this device it would have been seen by now so must be some form of configuration issue that I'm encountering hence the need for a simplified test platform to remove any possible cause from other configurations in the project.

When the device starts I use both pins as an EXTI interrupt source, and although it does not say so in the documentation I have also tried to reset these to using AFIO0 prior to enabling the wakeup mode on them in case it was a pending ISR that was causing the wakeup block.

I'll post my results as I find them.