<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Jython,<div class=""><br class=""></div><div class="">You may have better luck asking on the ST support forums. Your questions relate more to the inner workings of the STM32 sleep and interrupt facilities and less about RTEMS.</div><div class=""><br class=""></div><div class="">A<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2019-June-20, at 18:58, Jython <<a href="mailto:googcheng@gmail.com" class="">googcheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">handler <a href="https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b" class="">https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b</a></div><div class=""><br class=""></div><div class="">the main loop code <a href="https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078" class="">https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078</a></div><div class=""><br class=""></div><div class="">when i pressed key,
printf("loop begin\n"); does not print immediately <br class=""></div><div class="">so the sleep function does not break<br class=""></div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" class="">list@c-mauderer.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 20/06/2019 16:43, Jython wrote:<br class="">
> sleep function at the ending of loop, the loop did not begin intermediate<br class="">
<br class="">
So just that I understand it correctly: Your have a loop in a task that<br class="">
sends your processor to sleep at the end of the loop. Then you wake up<br class="">
the processor via an interrupt and the interrupt handler is executed.<br class="">
But you don't reach the loop again?<br class="">
<br class="">
I think I remember some discussion where you wanted to put a sleep into<br class="">
your idle loop? Maybe you have a double sleep?<br class="">
<br class="">
> <br class="">
> On Thursday, June 20, 2019, Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a><br class="">
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a>>> wrote:<br class="">
> <br class="">
> On 20/06/2019 13:25, Jython wrote:<br class="">
> > do have service routine, handler can printk log, SLEEPONEXIT is 0<br class="">
> <br class="">
> So your handler is called? But it seems that the processor wakes up<br class="">
> then. How does the "won't stop sleep mode" look like?<br class="">
> <br class="">
> ><br class="">
> > On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer<br class="">
> <<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a>><br class="">
> > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a>>>> wrote:<br class="">
> ><br class="">
> > On 20/06/2019 10:57, Jython wrote:<br class="">
> > > a GPIO EXTI line,<br class="">
> > > rtems idle phrase called __wfi, does it make stm32 enter<br class="">
> standby mode?<br class="">
> > > so key can not wake up it from sleep function<br class="">
> ><br class="">
> > Please take a look at the reference manual of your chip. Most<br class="">
> likely<br class="">
> > it's "RM0090 Rev 18" but make sure that's the right part number:<br class="">
> ><br class="">
> > <br class="">
> <a href="https://www.st.com/resource/en/reference_manual/dm00031020.pdf" rel="noreferrer" target="_blank" class="">https://www.st.com/resource/en/reference_manual/dm00031020.pdf</a><br class="">
> <<a href="https://www.st.com/resource/en/reference_manual/dm00031020.pdf" rel="noreferrer" target="_blank" class="">https://www.st.com/resource/en/reference_manual/dm00031020.pdf</a>><br class="">
> ><br class="">
> > On page 127 there is a description of "Entering low-power mode":<br class="">
> ><br class="">
> > "Low-power modes are entered by the MCU by executing the<br class="">
> WFI (Wait<br class="">
> > For Interrupt), or WFE (Wait for Event) instructions, or<br class="">
> when the<br class="">
> > SLEEPONEXIT bit in the Cortex ®-M4 with FPU System Control<br class="">
> > register is set on Return from ISR."<br class="">
> ><br class="">
> > There is also a description for "Exiting low-power mode". For<br class="">
> WFI "any<br class="">
> > peripheral interrupt acknowledged by the NVIC can wake up the<br class="">
> device."<br class="">
> > So your interrupt has to be set up.<br class="">
> ><br class="">
> > Your code seems to enable the interrupt. But have you registered a<br class="">
> > interrupt service routine? Otherwise you might get problems<br class="">
> with an<br class="">
> > unhandled interrupt on wakeup.<br class="">
> ><br class="">
> > I only skimmed through the power controller chapter. But it<br class="">
> seems that<br class="">
> > if you have SLEEPDEEP bit set, you will enter a deeper sleep mode<br class="">
> > where peripheral clocks can be disabled. In that state it's<br class="">
> possible<br class="">
> > that only special pins (like the WKUP) can wake up the processor<br class="">
> > again. Please have a detailed look at that chapter to find out all<br class="">
> > traps.<br class="">
> ><br class="">
> > Best regards<br class="">
> ><br class="">
> > Christian<br class="">
> ><br class="">
> > ><br class="">
> > ><br class="">
> > > void keys_init()<br class="">
> > > {<br class="">
> > > // config gpio<br class="">
> > > stm32f4_gpio_set_config(&io_key1); // PA12<br class="">
> > > stm32f4_gpio_set_config(&io_key2);<br class="">
> > > stm32f4_gpio_set_config(&io_key3);<br class="">
> > > stm32f4_gpio_set_config(&io_key4);<br class="">
> > ><br class="">
> > > <br class="">
> > > // SYSCFGEN and exit map<br class="">
> > > (*(uint32_t*)0x40023844) |= 1<<14;<br class="">
> > > <br class="">
> > > SYSCFG_EXTICR3 = 0;<br class="">
> > > SYSCFG_EXTICR4 = 0;<br class="">
> > > <br class="">
> > ><br class="">
> > ><br class="">
> > > // EXIT INIT<br class="">
> > > EXTI_IMR |= (1<<12);<br class="">
> > > EXTI_RTSR |= (1<<12);<br class="">
> > ><br class="">
> > > EXTI_IMR |= (1<<11);<br class="">
> > > EXTI_RTSR |= (1<<11);<br class="">
> > ><br class="">
> > > EXTI_IMR |= (1<<10);<br class="">
> > > EXTI_RTSR |= (1<<10);<br class="">
> > ><br class="">
> > > EXTI_IMR |= (1<<9);<br class="">
> > > EXTI_RTSR |= (1<<9);<br class="">
> > ><br class="">
> > ><br class="">
> > > //NVIC_Init<br class="">
> > > //NVIC it group2<br class="">
> > ><br class="">
> > > SCB_AIRCR = 0x05FA0000 | 0x500;<br class="">
> > > // ip Interrupt priority register x<br class="">
> > ><br class="">
> > > //(*(volatile uint8_t*)0xE000E417) = 0xe0; //23<br class="">
> > > //(*(volatile uint8_t*)0xE000E428) = 0xe0; // 40<br class="">
> > > (*(volatile uint8_t*)0xE000E417) = 0x50; //23<br class="">
> > > (*(volatile uint8_t*)0xE000E428) = 0x50; // 40<br class="">
> > ><br class="">
> > ><br class="">
> > ><br class="">
> > > // 23 40 Interrupt set-enable register x (NVIC_ISERx)<br class="">
> > > // nvic enable interrupter number<br class="">
> > > // 0xE000E100<br class="">
> > > (*(volatile uint32_t*)0xE000E100) |= (1<<23);<br class="">
> > > (*(volatile uint32_t *)0xE000E104) |= (1<< (40%32));<br class="">
> > > }<br class="">
> > ><br class="">
> > ><br class="">
> > > On Thu, Jun 20, 2019 at 4:05 PM Christian Mauderer<br class="">
> > <<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a>><br class="">
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a>>><br class="">
> > > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a>><br class="">
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank" class="">list@c-mauderer.de</a>>>>> wrote:<br class="">
> > ><br class="">
> > > On 20/06/2019 05:28, Jython wrote:<br class="">
> > > > hi, it seems that exit key interrupt won't stop sleep<br class="">
> mode, why?<br class="">
> > > ><br class="">
> > > > [...]<br class="">
> > > ><br class="">
> > ><br class="">
> > > What do you mean by "exit key interrupt"? I don't know the<br class="">
> > STM32F4 that<br class="">
> > > well. So please give some more details.<br class="">
> > ><br class="">
> > > I would expect that either only specific interrupt<br class="">
> sources can<br class="">
> > wake up<br class="">
> > > the processor from a deep sleep mode or that you can<br class="">
> configure<br class="">
> > which<br class="">
> > > peripherals are still active. If your "exit key" is a GPIO<br class="">
> > line with<br class="">
> > > interrupt capability you should have a look at whether the<br class="">
> > module is<br class="">
> > > still active.<br class="">
> > ><br class="">
> > > Best regards<br class="">
> > ><br class="">
> > > Christian<br class="">
> > ><br class="">
> > > _______________________________________________<br class="">
> > > users mailing list<br class="">
> > > <a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a>><br class="">
> <mailto:<a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a>>><br class="">
> > <mailto:<a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a>><br class="">
> <mailto:<a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank" class="">users@rtems.org</a>>>><br class="">
> > > <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank" class="">http://lists.rtems.org/mailman/listinfo/users</a><br class="">
> <<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank" class="">http://lists.rtems.org/mailman/listinfo/users</a>><br class="">
> > ><br class="">
> ><br class="">
> <br class="">
<br class="">
</blockquote></div>
_______________________________________________<br class="">users mailing list<br class=""><a href="mailto:users@rtems.org" class="">users@rtems.org</a><br class="">http://lists.rtems.org/mailman/listinfo/users</div></blockquote></div><br class=""></div></body></html>