stm32f4 __wfi
Christian Mauderer
christian.mauderer at embedded-brains.de
Mon Jun 24 07:44:55 UTC 2019
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.
More information about the users
mailing list