Jython, 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.
A > On 2019-June-20, at 18:58, Jython <googch...@gmail.com> wrote: > > > handler https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b > <https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b> > > the main loop code > https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078 > <https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078> > > when i pressed key, printf("loop begin\n"); does not print immediately > so the sleep function does not break > > > > On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer <l...@c-mauderer.de > <mailto:l...@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 <l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@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 > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@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> > > <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 > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@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@rtems.org <mailto:users@rtems.org> > > <mailto:users@rtems.org <mailto:users@rtems.org>> > > <mailto:users@rtems.org <mailto:users@rtems.org> > > <mailto:users@rtems.org <mailto:users@rtems.org>>> > > > <mailto:users@rtems.org <mailto:users@rtems.org> > > <mailto:users@rtems.org <mailto:users@rtems.org>> > > <mailto:users@rtems.org <mailto:users@rtems.org> > > <mailto:users@rtems.org <mailto:users@rtems.org>>>> > > > > http://lists.rtems.org/mailman/listinfo/users > > <http://lists.rtems.org/mailman/listinfo/users> > > <http://lists.rtems.org/mailman/listinfo/users > > <http://lists.rtems.org/mailman/listinfo/users>> > > > > > > > > > > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
