<div dir="ltr"><div>i got it , i have coded some low power applications with stm32cube last year, <br></div><div>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 ?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 21/06/2019 02:58, Jython wrote:<br>
> <br>
> handler <a href="https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b" rel="noreferrer" target="_blank">https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b</a><br>
<br>
There are some things that I would strongly discourage in that interrupt<br>
handler (printk as long as it is not only a temporary debug output,<br>
delay, ...) but it shouldn't be the problem. I assume that you already<br>
checked, that you are testing for the right flag in the first if. So I<br>
would expect that you get your debug output if your interrupt occurs.<br>
<br>
> <br>
> the main loop code<br>
> <a href="https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078" rel="noreferrer" target="_blank">https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078</a><br>
<br>
Same again: Some details but nothing that I would see as a cause for<br>
your problem.<br>
<br>
> <br>
> when i pressed key, printf("loop begin\n"); does not print immediately<br>
> so the sleep function does not break<br>
<br>
Note that printf is a interrupt driven print. So if you have problems<br>
with _some_ interrupts not waking up your device you might not get an<br>
output or maybe only a "l".<br>
<br>
I agree with the mail from "groups <a href="http://chichak.ca" rel="noreferrer" target="_blank">chichak.ca</a>". It's a problem that is<br>
very chip specific and not really a RTEMS specific one. So it might<br>
would be a good idea to search for "STM32 not waking up" in the ST forums.<br>
<br>
> <br>
> <br>
> <br>
> On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
> On 20/06/2019 16:43, Jython wrote:<br>
> > sleep function at the ending of loop, the loop did not begin<br>
> intermediate<br>
> <br>
> So just that I understand it correctly: Your have a loop in a task that<br>
> sends your processor to sleep at the end of the loop. Then you wake up<br>
> the processor via an interrupt and the interrupt handler is executed.<br>
> But you don't reach the loop again?<br>
> <br>
> I think I remember some discussion where you wanted to put a sleep into<br>
> your idle loop? Maybe you have a double sleep?<br>
> <br>
> ><br>
> > On Thursday, June 20, 2019, Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
> > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>
> ><br>
> > On 20/06/2019 13:25, Jython wrote:<br>
> > > do have service routine, handler can printk log, <br>
> SLEEPONEXIT is 0<br>
> ><br>
> > So your handler is called? But it seems that the processor<br>
> wakes up<br>
> > then. How does the "won't stop sleep mode" look like?<br>
> ><br>
> > ><br>
> > > On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer<br>
> > <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>
> > > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>> wrote:<br>
> > ><br>
> > > On 20/06/2019 10:57, Jython wrote:<br>
> > > > a GPIO EXTI line,<br>
> > > > rtems idle phrase called __wfi, does it make stm32 enter<br>
> > standby mode?<br>
> > > > so key can not wake up it from sleep function<br>
> > ><br>
> > > Please take a look at the reference manual of your chip.<br>
> Most<br>
> > likely<br>
> > > it's "RM0090 Rev 18" but make sure that's the right part<br>
> number:<br>
> > ><br>
> > > <br>
> > <a href="https://www.st.com/resource/en/reference_manual/dm00031020.pdf" rel="noreferrer" target="_blank">https://www.st.com/resource/en/reference_manual/dm00031020.pdf</a><br>
> > <<a href="https://www.st.com/resource/en/reference_manual/dm00031020.pdf" rel="noreferrer" target="_blank">https://www.st.com/resource/en/reference_manual/dm00031020.pdf</a>><br>
> > ><br>
> > > On page 127 there is a description of "Entering<br>
> low-power mode":<br>
> > ><br>
> > > "Low-power modes are entered by the MCU by executing the<br>
> > WFI (Wait<br>
> > > For Interrupt), or WFE (Wait for Event) instructions, or<br>
> > when the<br>
> > > SLEEPONEXIT bit in the Cortex ®-M4 with FPU System<br>
> Control<br>
> > > register is set on Return from ISR."<br>
> > ><br>
> > > There is also a description for "Exiting low-power<br>
> mode". For<br>
> > WFI "any<br>
> > > peripheral interrupt acknowledged by the NVIC can wake<br>
> up the<br>
> > device."<br>
> > > So your interrupt has to be set up.<br>
> > ><br>
> > > Your code seems to enable the interrupt. But have you<br>
> registered a<br>
> > > interrupt service routine? Otherwise you might get problems<br>
> > with an<br>
> > > unhandled interrupt on wakeup.<br>
> > ><br>
> > > I only skimmed through the power controller chapter. But it<br>
> > seems that<br>
> > > if you have SLEEPDEEP bit set, you will enter a deeper<br>
> sleep mode<br>
> > > where peripheral clocks can be disabled. In that state it's<br>
> > possible<br>
> > > that only special pins (like the WKUP) can wake up the<br>
> processor<br>
> > > again. Please have a detailed look at that chapter to<br>
> find out all<br>
> > > traps.<br>
> > ><br>
> > > Best regards<br>
> > ><br>
> > > Christian<br>
> > ><br>
> > > ><br>
> > > ><br>
> > > > void keys_init()<br>
> > > > {<br>
> > > > // config gpio<br>
> > > > stm32f4_gpio_set_config(&io_key1); // PA12<br>
> > > > stm32f4_gpio_set_config(&io_key2);<br>
> > > > stm32f4_gpio_set_config(&io_key3);<br>
> > > > stm32f4_gpio_set_config(&io_key4);<br>
> > > ><br>
> > > > <br>
> > > > // SYSCFGEN and exit map<br>
> > > > (*(uint32_t*)0x40023844) |= 1<<14;<br>
> > > > <br>
> > > > SYSCFG_EXTICR3 = 0;<br>
> > > > SYSCFG_EXTICR4 = 0;<br>
> > > > <br>
> > > ><br>
> > > ><br>
> > > > // EXIT INIT<br>
> > > > EXTI_IMR |= (1<<12);<br>
> > > > EXTI_RTSR |= (1<<12);<br>
> > > ><br>
> > > > EXTI_IMR |= (1<<11);<br>
> > > > EXTI_RTSR |= (1<<11);<br>
> > > ><br>
> > > > EXTI_IMR |= (1<<10);<br>
> > > > EXTI_RTSR |= (1<<10);<br>
> > > ><br>
> > > > EXTI_IMR |= (1<<9);<br>
> > > > EXTI_RTSR |= (1<<9);<br>
> > > ><br>
> > > ><br>
> > > > //NVIC_Init<br>
> > > > //NVIC it group2<br>
> > > ><br>
> > > > SCB_AIRCR = 0x05FA0000 | 0x500;<br>
> > > > // ip Interrupt priority register x<br>
> > > ><br>
> > > > //(*(volatile uint8_t*)0xE000E417) = 0xe0; //23<br>
> > > > //(*(volatile uint8_t*)0xE000E428) = 0xe0; // 40<br>
> > > > (*(volatile uint8_t*)0xE000E417) = 0x50; //23<br>
> > > > (*(volatile uint8_t*)0xE000E428) = 0x50; // 40<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > // 23 40 Interrupt set-enable register x (NVIC_ISERx)<br>
> > > > // nvic enable interrupter number<br>
> > > > // 0xE000E100<br>
> > > > (*(volatile uint32_t*)0xE000E100) |= (1<<23);<br>
> > > > (*(volatile uint32_t *)0xE000E104) |= (1<<<br>
> (40%32));<br>
> > > > }<br>
> > > ><br>
> > > ><br>
> > > > On Thu, Jun 20, 2019 at 4:05 PM Christian Mauderer<br>
> > > <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>
> > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>><br>
> > > > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>
> > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>>> wrote:<br>
> > > ><br>
> > > > On 20/06/2019 05:28, Jython wrote:<br>
> > > > > hi, it seems that exit key interrupt won't stop<br>
> sleep<br>
> > mode, why?<br>
> > > > ><br>
> > > > > [...]<br>
> > > > ><br>
> > > ><br>
> > > > What do you mean by "exit key interrupt"? I don't<br>
> know the<br>
> > > STM32F4 that<br>
> > > > well. So please give some more details.<br>
> > > ><br>
> > > > I would expect that either only specific interrupt<br>
> > sources can<br>
> > > wake up<br>
> > > > the processor from a deep sleep mode or that you can<br>
> > configure<br>
> > > which<br>
> > > > peripherals are still active. If your "exit key"<br>
> is a GPIO<br>
> > > line with<br>
> > > > interrupt capability you should have a look at<br>
> whether the<br>
> > > module is<br>
> > > > still active.<br>
> > > ><br>
> > > > Best regards<br>
> > > ><br>
> > > > Christian<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > users mailing list<br>
> > > > <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>>><br>
> > <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>>>><br>
> > > <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>>><br>
> > <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>>>>><br>
> > > > <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
> > <<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a>><br>
> > > ><br>
> > ><br>
> ><br>
> <br>
> <br>
> _______________________________________________<br>
> users mailing list<br>
> <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>