stm32f4 __wfi

Jython googcheng at gmail.com
Mon Jun 24 09:36:22 UTC 2019


now i have changed to RTC wakeup, my key press can wake up the board,

//rtems_stack_checker_report_usage();
>
>         PWR_EnterSTOPMode(1, 1);
>
>         init_main_osc();
>         usleep(100000);
>         printf("RCC_CFGR %02x\n", RCC_CFGR & 0xff);
>

so i think sleep function can't be wake up by EXTI


On Mon, Jun 24, 2019 at 3:44 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:

> On 24/06/2019 02:47, Jython wrote:
> > that's to say EXTI wakes up from sleep function because interrupt
> > handler log out
> > but _CPU_Thread_Idle_body does not exit ?  want to know what is the
> > sleep/idle exit condition?
>
> The idle task is the task with the lowest priority. So it runs if no
> other higher priority task (basically every task) is in the position to
> run. In your case, your main task has been send to sleep with the
> `sleep(10)` call. It should become active again after 10 seconds.
>
> I vaguely remember that there was something about disabling some timing
> mechanisms in your system. If you disabled the wrong parts, a sleep(10)
> might never wake up again because it's missing it's timer that
> determines whether 10 seconds passed. In that case you might want to
> wait for some synchronization object instead (a signal, a mutex, some
> event, ...) that you send from your interrupt.
>
> PS: I re-added the user list on CC. I hope that is OK for you.
>
> Best regards
>
> Christian
>
> >
> > On Fri, Jun 21, 2019 at 7:09 PM Christian Mauderer
> > <christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>> wrote:
> >
> >     On 21/06/2019 11:53, Jython wrote:
> >     > i got it ,  i have coded some low power applications with
> >     stm32cube last
> >     > year,
> >     > may i just want to know more about the sleep and why it does not
> >     stop by
> >     > EXTI , maybe i need to rewrite sleep function ?
> >
> >     `sleep()` just suspends your current task. So you will reach (after a
> >     task switch) the idle loop.
> >
> >     >
> >     > On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer
> >     > <christian.mauderer at embedded-brains.de
> >     <mailto:christian.mauderer at embedded-brains.de>
> >     > <mailto:christian.mauderer at embedded-brains.de
> >     <mailto:christian.mauderer at embedded-brains.de>>> wrote:
> >     >
> >     >     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
> >     <http://chichak.ca> <http://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>
> >     <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 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>>
> >     >     >     <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 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>>>
> >     >     >     <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 <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 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>>>>
> >     >     >     >     <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 <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>
> >     <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 <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>>>>
> >     >     >     >     <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 <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>
> >     <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 <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 <mailto:users at rtems.org>
> >     <mailto:users at rtems.org <mailto: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
> >     <mailto:christian.mauderer at embedded-brains.de>
> >     >     <mailto:christian.mauderer at embedded-brains.de
> >     <mailto: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.
> >     >
> >
> >     --
> >     --------------------------------------------
> >     embedded brains GmbH
> >     Herr Christian Mauderer
> >     Dornierstr. 4
> >     D-82178 Puchheim
> >     Germany
> >     email: christian.mauderer at embedded-brains.de
> >     <mailto: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.
> >
>
> --
> --------------------------------------------
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190624/25763c03/attachment-0001.html>


More information about the users mailing list