stm32f4 __wfi

Christian Mauderer christian.mauderer at embedded-brains.de
Fri Jun 21 07:16:28 UTC 2019


On 21/06/2019 02:58, Jython wrote:
> 
> handler https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b

There are some things that I would strongly discourage in that interrupt
handler (printk as long as it is not only a temporary debug output,
delay, ...) but it shouldn't be the problem. I assume that you already
checked, that you are testing for the right flag in the first if. So I
would expect that you get your debug output if your interrupt occurs.

> 
> the main loop code
> https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078

Same again: Some details but nothing that I would see as a cause for
your problem.

> 
> when i pressed key, printf("loop begin\n"); does not print immediately
> so the sleep function does not break

Note that printf is a interrupt driven print. So if you have problems
with _some_ interrupts not waking up your device you might not get an
output or maybe only a "l".

I agree with the mail from "groups chichak.ca". It's a problem that is
very chip specific and not really a RTEMS specific one. So it might
would be a good idea to search for "STM32 not waking up" in the ST forums.

> 
> 
> 
> On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer <list at c-mauderer.de
> <mailto:list at c-mauderer.de>> wrote:
> 
>     On 20/06/2019 16:43, Jython wrote:
>     > sleep function at the ending of loop, the loop did not begin
>     intermediate
> 
>     So just that I understand it correctly: Your have a loop in a task that
>     sends your processor to sleep at the end of the loop. Then you wake up
>     the processor via an interrupt and the interrupt handler is executed.
>     But you don't reach the loop again?
> 
>     I think I remember some discussion where you wanted to put a sleep into
>     your idle loop? Maybe you have a double sleep?
> 
>     >
>     > On Thursday, June 20, 2019, Christian Mauderer <list at c-mauderer.de
>     <mailto:list at c-mauderer.de>
>     > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>> wrote:
>     >
>     >     On 20/06/2019 13:25, Jython wrote:
>     >     > do have service routine,  handler can printk log, 
>     SLEEPONEXIT is 0
>     >
>     >     So your handler is called? But it seems that the processor
>     wakes up
>     >     then. How does the "won't stop sleep mode" look like?
>     >
>     >     >
>     >     > On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer
>     >     <list at c-mauderer.de <mailto:list at c-mauderer.de>
>     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
>     >     > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
>     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>> wrote:
>     >     >
>     >     >     On 20/06/2019 10:57, Jython wrote:
>     >     >     > a GPIO EXTI line,
>     >     >     > rtems idle phrase called __wfi, does it make stm32 enter
>     >     standby mode?
>     >     >     > so key can not wake up it from sleep function
>     >     >
>     >     >     Please take a look at the reference manual of your chip.
>     Most
>     >     likely
>     >     >     it's "RM0090 Rev 18" but make sure that's the right part
>     number:
>     >     >
>     >     >        
>     >     https://www.st.com/resource/en/reference_manual/dm00031020.pdf
>     >     <https://www.st.com/resource/en/reference_manual/dm00031020.pdf>
>     >     >
>     >     >     On page 127 there is a description of "Entering
>     low-power mode":
>     >     >
>     >     >         "Low-power modes are entered by the MCU by executing the
>     >     WFI (Wait
>     >     >         For Interrupt), or WFE (Wait for Event) instructions, or
>     >     when the
>     >     >         SLEEPONEXIT bit in the Cortex ®-M4 with FPU System
>     Control
>     >     >         register is set on Return from ISR."
>     >     >
>     >     >     There is also a description for "Exiting low-power
>     mode". For
>     >     WFI "any
>     >     >     peripheral interrupt acknowledged by the NVIC can wake
>     up the
>     >     device."
>     >     >     So your interrupt has to be set up.
>     >     >
>     >     >     Your code seems to enable the interrupt. But have you
>     registered a
>     >     >     interrupt service routine? Otherwise you might get problems
>     >     with an
>     >     >     unhandled interrupt on wakeup.
>     >     >
>     >     >     I only skimmed through the power controller chapter. But it
>     >     seems that
>     >     >     if you have SLEEPDEEP bit set, you will enter a deeper
>     sleep mode
>     >     >     where peripheral clocks can be disabled. In that state it's
>     >     possible
>     >     >     that only special pins (like the WKUP) can wake up the
>     processor
>     >     >     again. Please have a detailed look at that chapter to
>     find out all
>     >     >     traps.
>     >     >
>     >     >     Best regards
>     >     >
>     >     >     Christian
>     >     >
>     >     >     >
>     >     >     >
>     >     >     >     void keys_init()
>     >     >     >     {
>     >     >     >         // config gpio
>     >     >     >     stm32f4_gpio_set_config(&io_key1);  // PA12
>     >     >     >     stm32f4_gpio_set_config(&io_key2);
>     >     >     >         stm32f4_gpio_set_config(&io_key3);
>     >     >     >     stm32f4_gpio_set_config(&io_key4);
>     >     >     >
>     >     >     >       
>     >     >     >         //  SYSCFGEN and exit map
>     >     >     >     (*(uint32_t*)0x40023844) |= 1<<14;
>     >     >     >       
>     >     >     >         SYSCFG_EXTICR3 = 0;
>     >     >     >         SYSCFG_EXTICR4 = 0;
>     >     >     >       
>     >     >     >
>     >     >     >
>     >     >     >         // EXIT INIT
>     >     >     >     EXTI_IMR |= (1<<12);
>     >     >     >     EXTI_RTSR |= (1<<12);
>     >     >     >
>     >     >     >         EXTI_IMR |= (1<<11);
>     >     >     >     EXTI_RTSR |= (1<<11);
>     >     >     >
>     >     >     >         EXTI_IMR |= (1<<10);
>     >     >     >     EXTI_RTSR |= (1<<10);
>     >     >     >
>     >     >     >         EXTI_IMR |= (1<<9);
>     >     >     >     EXTI_RTSR |= (1<<9);
>     >     >     >
>     >     >     >
>     >     >     >         //NVIC_Init
>     >     >     >         //NVIC it group2
>     >     >     >
>     >     >     >     SCB_AIRCR = 0x05FA0000 | 0x500;
>     >     >     >     // ip Interrupt priority register x
>     >     >     >
>     >     >     >     //(*(volatile uint8_t*)0xE000E417) = 0xe0;  //23
>     >     >     >         //(*(volatile uint8_t*)0xE000E428) = 0xe0;  // 40
>     >     >     >         (*(volatile uint8_t*)0xE000E417) = 0x50;  //23
>     >     >     >         (*(volatile uint8_t*)0xE000E428) = 0x50;  // 40
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     // 23 40 Interrupt set-enable register x (NVIC_ISERx)
>     >     >     >         // nvic enable interrupter number
>     >     >     >         // 0xE000E100
>     >     >     >         (*(volatile uint32_t*)0xE000E100) |= (1<<23);
>     >     >     >         (*(volatile uint32_t *)0xE000E104) |= (1<<
>     (40%32));
>     >     >     >     }
>     >     >     >
>     >     >     >
>     >     >     > On Thu, Jun 20, 2019 at 4:05 PM Christian Mauderer
>     >     >     <list at c-mauderer.de <mailto:list at c-mauderer.de>
>     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
>     >     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
>     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
>     >     >     > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
>     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
>     >     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
>     <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>> wrote:
>     >     >     >
>     >     >     >     On 20/06/2019 05:28, Jython wrote:
>     >     >     >     > hi, it seems that exit key interrupt won't stop
>     sleep
>     >     mode, why?
>     >     >     >     >
>     >     >     >     > [...]
>     >     >     >     >
>     >     >     >
>     >     >     >     What do you mean by "exit key interrupt"? I don't
>     know the
>     >     >     STM32F4 that
>     >     >     >     well. So please give some more details.
>     >     >     >
>     >     >     >     I would expect that either only specific interrupt
>     >     sources can
>     >     >     wake up
>     >     >     >     the processor from a deep sleep mode or that you can
>     >     configure
>     >     >     which
>     >     >     >     peripherals are still active. If your "exit key"
>     is a GPIO
>     >     >     line with
>     >     >     >     interrupt capability you should have a look at
>     whether the
>     >     >     module is
>     >     >     >     still active.
>     >     >     >
>     >     >     >     Best regards
>     >     >     >
>     >     >     >     Christian
>     >     >     >
>     >     >     >     _______________________________________________
>     >     >     >     users mailing list
>     >     >     >     users at rtems.org <mailto:users at rtems.org>
>     <mailto:users at rtems.org <mailto:users at rtems.org>>
>     >     <mailto:users at rtems.org <mailto:users at rtems.org>
>     <mailto:users at rtems.org <mailto:users at rtems.org>>>
>     >     >     <mailto:users at rtems.org <mailto:users at rtems.org>
>     <mailto:users at rtems.org <mailto:users at rtems.org>>
>     >     <mailto:users at rtems.org <mailto:users at rtems.org>
>     <mailto:users at rtems.org <mailto:users at rtems.org>>>>
>     >     >     >     http://lists.rtems.org/mailman/listinfo/users
>     >     <http://lists.rtems.org/mailman/listinfo/users>
>     >     >     >
>     >     >
>     >
> 
> 
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the users mailing list