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 <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> > > > > > > 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> > > > > > > > > > > > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users > -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@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. _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
