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