Re: stm32f4 __wfi

[Jython]

this is the configure:

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER

#define CONFIGURE_MAXIMUM_TASKS 5
#define CONFIGURE_MAXIMUM_TIMERS3

#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_STACK_CHECKER_ENABLED
#define CONFIGURE_INIT_TASK_STACK_SIZE (RTEMS_MINIMUM_STACK_SIZE * 2)
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 20
#define CONFIGURE_INIT

On Mon, Jun 24, 2019 at 7:01 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 24/06/2019 11:36, Jython wrote:
> > now i have changed to RTC wakeup, my key press can wake up the board,
> >
> > //rtems_stack_checker_report_usage();
> >
> > PWR_EnterSTOPMode(1, 1);
> >
> > init_main_osc();
> > usleep(10);
> > printf("RCC_CFGR %02x\n", RCC_CFGR & 0xff);
> >
> >
> > so i think sleep function can't be wake up by EXTI
>
> Did you disable some time-specific functionality in your applications
> configuration? For example a
> CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER.
>
> >
> >
> > On Mon, Jun 24, 2019 at 3:44 PM Christian Mauderer
> >  > > wrote:
> >
> > On 24/06/2019 02:47, Jython wrote:
> > > that's to say EXTI wakes up from sleep function because interrupt
> > > handler log out
> > > but _CPU_Thread_Idle_body does not exit ?  want to know what is the
> > > sleep/idle exit condition?
> >
> > The idle task is the task with the lowest priority. So it runs if no
> > other higher priority task (basically every task) is in the position
> to
> > run. In your case, your main task has been send to sleep with the
> > `sleep(10)` call. It should become active again after 10 seconds.
> >
> > I vaguely remember that there was something about disabling some
> timing
> > mechanisms in your system. If you disabled the wrong parts, a
> sleep(10)
> > might never wake up again because it's missing it's timer that
> > determines whether 10 seconds passed. In that case you might want to
> > wait for some synchronization object instead (a signal, a mutex, some
> > event, ...) that you send from your interrupt.
> >
> > PS: I re-added the user list on CC. I hope that is OK for you.
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > On Fri, Jun 21, 2019 at 7:09 PM Christian Mauderer
> > >  > 
> > >  > >> wrote:
> > >
> > > On 21/06/2019 11:53, Jython wrote:
> > > > i got it ,  i have coded some low power applications with
> > > stm32cube last
> > > > year,
> > > > 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 ?
> > >
> > > `sleep()` just suspends your current task. So you will reach
> > (after a
> > > task switch) the idle loop.
> > >
> > > >
> > > > On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer
> > > >  > 
> > >  > >
> > > >  > 
> > >  >  > > >
> > > > 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
> >   

Re: stm32f4 __wfi

[Jython]

now i have changed to RTC wakeup, my key press can wake up the board,

//rtems_stack_checker_report_usage();
>
> PWR_EnterSTOPMode(1, 1);
>
> init_main_osc();
> usleep(10);
> printf("RCC_CFGR %02x\n", RCC_CFGR & 0xff);
>

so i think sleep function can't be wake up by EXTI


On Mon, Jun 24, 2019 at 3:44 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 24/06/2019 02:47, Jython wrote:
> > that's to say EXTI wakes up from sleep function because interrupt
> > handler log out
> > but _CPU_Thread_Idle_body does not exit ?  want to know what is the
> > sleep/idle exit condition?
>
> The idle task is the task with the lowest priority. So it runs if no
> other higher priority task (basically every task) is in the position to
> run. In your case, your main task has been send to sleep with the
> `sleep(10)` call. It should become active again after 10 seconds.
>
> I vaguely remember that there was something about disabling some timing
> mechanisms in your system. If you disabled the wrong parts, a sleep(10)
> might never wake up again because it's missing it's timer that
> determines whether 10 seconds passed. In that case you might want to
> wait for some synchronization object instead (a signal, a mutex, some
> event, ...) that you send from your interrupt.
>
> PS: I re-added the user list on CC. I hope that is OK for you.
>
> Best regards
>
> Christian
>
> >
> > On Fri, Jun 21, 2019 at 7:09 PM Christian Mauderer
> >  > > wrote:
> >
> > On 21/06/2019 11:53, Jython wrote:
> > > i got it ,  i have coded some low power applications with
> > stm32cube last
> > > year,
> > > 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 ?
> >
> > `sleep()` just suspends your current task. So you will reach (after a
> > task switch) the idle loop.
> >
> > >
> > > On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer
> > >  > 
> > >  > >> wrote:
> > >
> > > 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
> > > mailto:l...@c-mauderer.de>
> > >
> > > > 
> >  > > >
> > > > 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
> > > 

Re: stm32f4 __wfi

[Christian Mauderer]

On 24/06/2019 02:47, Jython wrote:
> that's to say EXTI wakes up from sleep function because interrupt
> handler log out
> but _CPU_Thread_Idle_body does not exit ?  want to know what is the
> sleep/idle exit condition?

The idle task is the task with the lowest priority. So it runs if no
other higher priority task (basically every task) is in the position to
run. In your case, your main task has been send to sleep with the
`sleep(10)` call. It should become active again after 10 seconds.

I vaguely remember that there was something about disabling some timing
mechanisms in your system. If you disabled the wrong parts, a sleep(10)
might never wake up again because it's missing it's timer that
determines whether 10 seconds passed. In that case you might want to
wait for some synchronization object instead (a signal, a mutex, some
event, ...) that you send from your interrupt.

PS: I re-added the user list on CC. I hope that is OK for you.

Best regards

Christian

> 
> On Fri, Jun 21, 2019 at 7:09 PM Christian Mauderer
>  > wrote:
> 
> On 21/06/2019 11:53, Jython wrote:
> > i got it ,  i have coded some low power applications with
> stm32cube last
> > year,
> > 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 ?
> 
> `sleep()` just suspends your current task. So you will reach (after a
> task switch) the idle loop.
> 
> >
> > On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer
> >  
> >  >> wrote:
> >
> >     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
> >     mailto:l...@c-mauderer.de>
> >
> >     > 
>  >     >
> >     >     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
> >     mailto:l...@c-mauderer.de>
> >
> >     >     
> >>
> >     >     > 
> >
> >     
> 

Re: stm32f4 __wfi

[Christian Mauderer]

On 21/06/2019 11:53, Jython wrote:
> i got it ,  i have coded some low power applications with stm32cube last
> year,
> 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 ?

`sleep()` just suspends your current task. So you will reach (after a
task switch) the idle loop.

> 
> On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer
>  > wrote:
> 
> 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
> 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
> mailto:l...@c-mauderer.de>
> >     >
> >     > 
>  >     >
> >     >     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
> >     >     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
> >     >   
>  
> >     >     >
> >     >     >     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 

Re: stm32f4 __wfi

[Jython]

i got it ,  i have coded some low power applications with stm32cube last
year,
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 ?

On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> 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  > > 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  > 
> > > >> 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
> > > mailto:l...@c-mauderer.de>
> > >
> > > > 
> >  > > >
> > > > 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 

Re: stm32f4 __wfi

[Christian Mauderer]

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  > 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  
> > >> 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
> >     mailto:l...@c-mauderer.de>
> >
> >     > 
>  >     >
> >     >     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
> >     
> >     >
> >     >     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()
> >     >     >     {
> >     >     >         // 

Re: stm32f4 __wfi

[groups]

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  wrote:
> 
> 
> handler https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b 
> 
> 
> the main loop code 
> 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  > 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  > 
> > >> 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
> > mailto:l...@c-mauderer.de> 
> > >
> > >  
> >  > >
> > > 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 
> > 
> >  > >
> > >
> > > 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(_key1);  // PA12
> > > > stm32f4_gpio_set_config(_key2);
> > > > stm32f4_gpio_set_config(_key3);
> > > > stm32f4_gpio_set_config(_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);
> >

Re: stm32f4 __wfi

[Jython]

handler https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b

the main loop code
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 
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  > > 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
> > 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
> > 
> > >
> > > 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(_key1);  // PA12
> > > > stm32f4_gpio_set_config(_key2);
> > > > stm32f4_gpio_set_config(_key3);
> > > > stm32f4_gpio_set_config(_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 = 0x05FA | 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;  

Re: stm32f4 __wfi

[Christian Mauderer]

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  > 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
> 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
> 
> >
> >     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(_key1);  // PA12
> >     >     stm32f4_gpio_set_config(_key2);
> >     >         stm32f4_gpio_set_config(_key3);
> >     >     stm32f4_gpio_set_config(_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 = 0x05FA | 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
> >     mailto:l...@c-mauderer.de>
> 

Re: stm32f4 __wfi

[Jython]

sleep function at the ending of loop, the loop did not begin intermediate

On Thursday, June 20, 2019, Christian Mauderer  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  > > 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
> >
> > 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(_key1);  // PA12
> > > stm32f4_gpio_set_config(_key2);
> > > stm32f4_gpio_set_config(_key3);
> > > stm32f4_gpio_set_config(_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 = 0x05FA | 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
> > 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 
> > 

Re: stm32f4 __wfi

[Christian Mauderer]

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  > 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
> 
> 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(_key1);  // PA12
> >     stm32f4_gpio_set_config(_key2);
> >         stm32f4_gpio_set_config(_key3);
> >     stm32f4_gpio_set_config(_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 = 0x05FA | 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
> 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 
> >
> >     http://lists.rtems.org/mailman/listinfo/users
> >
> 

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32f4 __wfi

[Jython]

do have service routine,  handler can printk log,  SLEEPONEXIT is 0

On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer 
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
>
> 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(_key1);  // PA12
> > stm32f4_gpio_set_config(_key2);
> > stm32f4_gpio_set_config(_key3);
> > stm32f4_gpio_set_config(_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 = 0x05FA | 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  > > 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 
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32f4 __wfi

[Christian Mauderer]

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

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(_key1);  // PA12
> stm32f4_gpio_set_config(_key2);
> stm32f4_gpio_set_config(_key3);
> stm32f4_gpio_set_config(_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 = 0x05FA | 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  > 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 
> http://lists.rtems.org/mailman/listinfo/users
> 

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32f4 __wfi

[Jython]

 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


void keys_init()
> {
> // config gpio
> stm32f4_gpio_set_config(_key1);  // PA12
> stm32f4_gpio_set_config(_key2);
> stm32f4_gpio_set_config(_key3);
> stm32f4_gpio_set_config(_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 = 0x05FA | 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 
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
> http://lists.rtems.org/mailman/listinfo/users
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32f4 __wfi

[Christian Mauderer]

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
http://lists.rtems.org/mailman/listinfo/users

Re: stm32f4 __wfi

[Christian Mauderer]

The system tick is responsible for everything timing relevant in RTEMS.
So if you want to use functions like sleep or rtems_task_wake_after, you
need a tick. If you don't want to use anything timing relevant, you can
disable that by (I think) using

CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER

But please be aware that with that nothing which needs the system to
wait for a given time would work any more.

Am 24.04.19 um 11:04 schrieb Jython:
> Thanks for your quick reply!
> the system will wake up every tick, why? does it effect the RTC wakeup?
> i am also debugging the rtc wakeup, have posted a mail
> https://lists.rtems.org/pipermail/users/2019-April/033176.html
> 
> On Wed, Apr 24, 2019 at 4:48 PM Christian Mauderer
>  > wrote:
> 
> There is the wfi in the Idle body. So as soon as all your tasks are
> sleeping (via sleep(), rtems_task_wake_after(), waiting for some signals
> or similar functions) wfi will be called.
> 
> Note that there most likely is a lot of potential in the drivers to save
> power. Also note that the system will wake up every tick. So depending
> on your configuration the power consumption will vary.
> 
> Am 24.04.19 um 10:44 schrieb Jython:
> > i searched it by add -i 
> >
> > 56794:d040 <_CPU_Thread_Idle_body>:
> > 56795-#ifdef ARM_MULTILIB_HAS_WFI
> > 56796-
> > 56797:void *_CPU_Thread_Idle_body( uintptr_t ignored )
> > 56798-{
> > 56799-  while ( true ) {
> > 56800-    __asm__ volatile ("wfi");
> > 56801-    d040:    bf30      wfi
> > 56802-  }
> > 56803:    d042:    e7fd      b.n    d040 <_CPU_Thread_Idle_body>
> > 56804-
> > 56805-d044 :
> > 56806-int rtems_filesystem_default_close(
> > 56807-  rtems_libio_t *iop
> > 56808-)
> > 56809-{
> > 56810-  return 0;
> > 56811-}
> > 56812-    d044:    2000      movs    r0, #0
> > 56813-    d046:    4770      bx    lr
> >
> >
> > that's to say when i want to enter low power  i just need to call
> sleep
> > or rtems_task_wake_after or just while(1); ?
> >
> > On Wed, Apr 24, 2019 at 4:36 PM Christian Mauderer
> >  
> >  >> wrote:
> >
> >     For some reason your grep hasn't found the
> _CPU_Thread_Idle_body. It's
> >     possible that the stm32f4 uses some other function for that
> also I don't
> >     know why.
> >
> >     For example for the xilinx_zynq_a9_qemu BSP the disassembled
> idle body
> >     looks like follows:
> >
> >     void *_CPU_Thread_Idle_body( uintptr_t ignored )
> >     {
> >        11d70:       b480            push    {r7}
> >        11d72:       b083            sub     sp, #12
> >        11d74:       af00            add     r7, sp, #0
> >        11d76:       6078            str     r0, [r7, #4]
> >       while ( true ) {
> >     #ifdef ARM_MULTILIB_HAS_WFI
> >         __asm__ volatile ("wfi");
> >        11d78:       bf30            wfi
> >        11d7a:       e7fd            b.n     11d78
> >     <_CPU_Thread_Idle_body+0x8>
> >
> >     Am 24.04.19 um 10:25 schrieb Jython:
> >     > arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto
> -n -B
> >     5 -A 12
> >     >
> >     > there is no idle function which calls wfi command
> >     > // log
> >     > 508-       
> >     > 509-       
> >     > 510-               
> >     > 511-    }
> >     > 512-   
> >     > 513:    if((*USART2_SR) & (1<<4))  // idle
> >     > 514- 3aa:    4b13      ldr    r3, [pc, #76]    ; (3f8
> >     > )
> >     > 515- 3ac:    681b      ldr    r3, [r3, #0]
> >     > 516- 3ae:    681b      ldr    r3, [r3, #0]
> >     > 517- 3b0:    f003 0310     and.w    r3, r3, #16
> >     > 518- 3b4:    2b00      cmp    r3, #0
> >     > 519- 3b6:    d00a      beq.n    3ce
> 
> >     > 520-    {
> >     > 521:        //printk("idle ");
> >     > 522-   
> >     > 523-    temp = (*USART2_SR);
> >     > 524- 3b8:    4b0f      ldr    r3, [pc, #60]    ; (3f8
> >     > )
> >     > 525- 3ba:    681b      ldr    r3, [r3, #0]
> >     > 526- 3bc:    681b      ldr    r3, [r3, #0]
> >     > 527- 3be:    60fb      str    r3, [r7, #12]
> >     > 528-        temp = (*USART2_DR);
> >     > 529- 3c0:    4b0f      ldr    r3, [pc, #60]    ; (400
> >     > )
> >     > 530- 3c2:    681b      ldr    r3, [r3, #0]
> >     > 531- 3c4:    681b      ldr    r3, [r3, #0]
> >     > 532- 3c6:    60fb      str    r3, [r7, #12]
> >     > 533-    //temp 

Re: stm32f4 __wfi

[Jython]

Thanks for your quick reply!
the system will wake up every tick, why? does it effect the RTC wakeup?
i am also debugging the rtc wakeup, have posted a mail
https://lists.rtems.org/pipermail/users/2019-April/033176.html

On Wed, Apr 24, 2019 at 4:48 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> There is the wfi in the Idle body. So as soon as all your tasks are
> sleeping (via sleep(), rtems_task_wake_after(), waiting for some signals
> or similar functions) wfi will be called.
>
> Note that there most likely is a lot of potential in the drivers to save
> power. Also note that the system will wake up every tick. So depending
> on your configuration the power consumption will vary.
>
> Am 24.04.19 um 10:44 schrieb Jython:
> > i searched it by add -i
> >
> > 56794:d040 <_CPU_Thread_Idle_body>:
> > 56795-#ifdef ARM_MULTILIB_HAS_WFI
> > 56796-
> > 56797:void *_CPU_Thread_Idle_body( uintptr_t ignored )
> > 56798-{
> > 56799-  while ( true ) {
> > 56800-__asm__ volatile ("wfi");
> > 56801-d040:bf30  wfi
> > 56802-  }
> > 56803:d042:e7fd  b.nd040 <_CPU_Thread_Idle_body>
> > 56804-
> > 56805-d044 :
> > 56806-int rtems_filesystem_default_close(
> > 56807-  rtems_libio_t *iop
> > 56808-)
> > 56809-{
> > 56810-  return 0;
> > 56811-}
> > 56812-d044:2000  movsr0, #0
> > 56813-d046:4770  bxlr
> >
> >
> > that's to say when i want to enter low power  i just need to call sleep
> > or rtems_task_wake_after or just while(1); ?
> >
> > On Wed, Apr 24, 2019 at 4:36 PM Christian Mauderer
> >  > > wrote:
> >
> > For some reason your grep hasn't found the _CPU_Thread_Idle_body.
> It's
> > possible that the stm32f4 uses some other function for that also I
> don't
> > know why.
> >
> > For example for the xilinx_zynq_a9_qemu BSP the disassembled idle
> body
> > looks like follows:
> >
> > void *_CPU_Thread_Idle_body( uintptr_t ignored )
> > {
> >11d70:   b480push{r7}
> >11d72:   b083sub sp, #12
> >11d74:   af00add r7, sp, #0
> >11d76:   6078str r0, [r7, #4]
> >   while ( true ) {
> > #ifdef ARM_MULTILIB_HAS_WFI
> > __asm__ volatile ("wfi");
> >11d78:   bf30wfi
> >11d7a:   e7fdb.n 11d78
> > <_CPU_Thread_Idle_body+0x8>
> >
> > Am 24.04.19 um 10:25 schrieb Jython:
> > > arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto -n -B
> > 5 -A 12
> > >
> > > there is no idle function which calls wfi command
> > > // log
> > > 508-
> > > 509-
> > > 510-
> > > 511-}
> > > 512-
> > > 513:if((*USART2_SR) & (1<<4))  // idle
> > > 514- 3aa:4b13  ldrr3, [pc, #76]; (3f8
> > > )
> > > 515- 3ac:681b  ldrr3, [r3, #0]
> > > 516- 3ae:681b  ldrr3, [r3, #0]
> > > 517- 3b0:f003 0310 and.wr3, r3, #16
> > > 518- 3b4:2b00  cmpr3, #0
> > > 519- 3b6:d00a  beq.n3ce 
> > > 520-{
> > > 521://printk("idle ");
> > > 522-
> > > 523-temp = (*USART2_SR);
> > > 524- 3b8:4b0f  ldrr3, [pc, #60]; (3f8
> > > )
> > > 525- 3ba:681b  ldrr3, [r3, #0]
> > > 526- 3bc:681b  ldrr3, [r3, #0]
> > > 527- 3be:60fb  strr3, [r7, #12]
> > > 528-temp = (*USART2_DR);
> > > 529- 3c0:4b0f  ldrr3, [pc, #60]; (400
> > > )
> > > 530- 3c2:681b  ldrr3, [r3, #0]
> > > 531- 3c4:681b  ldrr3, [r3, #0]
> > > 532- 3c6:60fb  strr3, [r7, #12]
> > > 533-//temp = temp;
> > > --
> > > 627-
> > > 628-
> > > 629-
> > > 630-}
> > > 631-
> > > 632:if((*USART3_SR) & (1<<4))  // idle
> > > 633- 44c:4b12  ldrr3, [pc, #72]; (498
> > > )
> > > 634- 44e:681b  ldrr3, [r3, #0]
> > > 635- 450:681b  ldrr3, [r3, #0]
> > > 636- 452:f003 0310 and.wr3, r3, #16
> > > 637- 456:2b00  cmpr3, #0
> > > 638- 458:d00a  beq.n470 
> > > 639-{
> > > 640://printk("idle ");
> > > 641-
> > > 642-temp = (*USART3_SR);
> > > 643- 45a:4b0f  ldrr3, [pc, #60]; (498
> > > )
> > > 644- 45c:681b  ldrr3, [r3, #0]
> > > 645- 45e:681b  ldrr3, [r3, #0]
> > > 646- 460:60fb  strr3, [r7, #12]
> > > 647-temp = (*USART3_DR);
> > > 648- 462:4b0f  ldrr3, [pc, #60]; 

Re: stm32f4 __wfi

[Christian Mauderer]

There is the wfi in the Idle body. So as soon as all your tasks are
sleeping (via sleep(), rtems_task_wake_after(), waiting for some signals
or similar functions) wfi will be called.

Note that there most likely is a lot of potential in the drivers to save
power. Also note that the system will wake up every tick. So depending
on your configuration the power consumption will vary.

Am 24.04.19 um 10:44 schrieb Jython:
> i searched it by add -i 
> 
> 56794:d040 <_CPU_Thread_Idle_body>:
> 56795-#ifdef ARM_MULTILIB_HAS_WFI
> 56796-
> 56797:void *_CPU_Thread_Idle_body( uintptr_t ignored )
> 56798-{
> 56799-  while ( true ) {
> 56800-    __asm__ volatile ("wfi");
> 56801-    d040:    bf30      wfi
> 56802-  }
> 56803:    d042:    e7fd      b.n    d040 <_CPU_Thread_Idle_body>
> 56804-
> 56805-d044 :
> 56806-int rtems_filesystem_default_close(
> 56807-  rtems_libio_t *iop
> 56808-)
> 56809-{
> 56810-  return 0;
> 56811-}
> 56812-    d044:    2000      movs    r0, #0
> 56813-    d046:    4770      bx    lr
> 
> 
> that's to say when i want to enter low power  i just need to call sleep
> or rtems_task_wake_after or just while(1); ?
> 
> On Wed, Apr 24, 2019 at 4:36 PM Christian Mauderer
>  > wrote:
> 
> For some reason your grep hasn't found the _CPU_Thread_Idle_body. It's
> possible that the stm32f4 uses some other function for that also I don't
> know why.
> 
> For example for the xilinx_zynq_a9_qemu BSP the disassembled idle body
> looks like follows:
> 
> void *_CPU_Thread_Idle_body( uintptr_t ignored )
> {
>    11d70:       b480            push    {r7}
>    11d72:       b083            sub     sp, #12
>    11d74:       af00            add     r7, sp, #0
>    11d76:       6078            str     r0, [r7, #4]
>   while ( true ) {
> #ifdef ARM_MULTILIB_HAS_WFI
>     __asm__ volatile ("wfi");
>    11d78:       bf30            wfi
>    11d7a:       e7fd            b.n     11d78
> <_CPU_Thread_Idle_body+0x8>
> 
> Am 24.04.19 um 10:25 schrieb Jython:
> > arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto -n -B
> 5 -A 12
> >
> > there is no idle function which calls wfi command
> > // log
> > 508-       
> > 509-       
> > 510-               
> > 511-    }
> > 512-   
> > 513:    if((*USART2_SR) & (1<<4))  // idle
> > 514- 3aa:    4b13      ldr    r3, [pc, #76]    ; (3f8
> > )
> > 515- 3ac:    681b      ldr    r3, [r3, #0]
> > 516- 3ae:    681b      ldr    r3, [r3, #0]
> > 517- 3b0:    f003 0310     and.w    r3, r3, #16
> > 518- 3b4:    2b00      cmp    r3, #0
> > 519- 3b6:    d00a      beq.n    3ce 
> > 520-    {
> > 521:        //printk("idle ");
> > 522-   
> > 523-    temp = (*USART2_SR);
> > 524- 3b8:    4b0f      ldr    r3, [pc, #60]    ; (3f8
> > )
> > 525- 3ba:    681b      ldr    r3, [r3, #0]
> > 526- 3bc:    681b      ldr    r3, [r3, #0]
> > 527- 3be:    60fb      str    r3, [r7, #12]
> > 528-        temp = (*USART2_DR);
> > 529- 3c0:    4b0f      ldr    r3, [pc, #60]    ; (400
> > )
> > 530- 3c2:    681b      ldr    r3, [r3, #0]
> > 531- 3c4:    681b      ldr    r3, [r3, #0]
> > 532- 3c6:    60fb      str    r3, [r7, #12]
> > 533-    //temp = temp;
> > --
> > 627-       
> > 628-       
> > 629-               
> > 630-    }
> > 631-   
> > 632:    if((*USART3_SR) & (1<<4))  // idle
> > 633- 44c:    4b12      ldr    r3, [pc, #72]    ; (498
> > )
> > 634- 44e:    681b      ldr    r3, [r3, #0]
> > 635- 450:    681b      ldr    r3, [r3, #0]
> > 636- 452:    f003 0310     and.w    r3, r3, #16
> > 637- 456:    2b00      cmp    r3, #0
> > 638- 458:    d00a      beq.n    470 
> > 639-    {
> > 640:        //printk("idle ");
> > 641-   
> > 642-    temp = (*USART3_SR);
> > 643- 45a:    4b0f      ldr    r3, [pc, #60]    ; (498
> > )
> > 644- 45c:    681b      ldr    r3, [r3, #0]
> > 645- 45e:    681b      ldr    r3, [r3, #0]
> > 646- 460:    60fb      str    r3, [r7, #12]
> > 647-        temp = (*USART3_DR);
> > 648- 462:    4b0f      ldr    r3, [pc, #60]    ; (4a0
> > )
> > 649- 464:    681b      ldr    r3, [r3, #0]
> > 650- 466:    681b      ldr    r3, [r3, #0]
> > 651- 468:    60fb      str    r3, [r7, #12]
> > 652-   
> > --
> > 26329-
> > 26330-    if (newTail == tty->rawOutBuf.Head) {
> > 26331-  /*
> > 26332-   * Buffer has become empty
> > 26333-   */
> > 26334:  tty->rawOutBufState = rob_idle;
> > 26335-    69a0:    f880 

Re: stm32f4 __wfi

[Jython]

i searched it by add -i

56794:d040 <_CPU_Thread_Idle_body>:
56795-#ifdef ARM_MULTILIB_HAS_WFI
56796-
56797:void *_CPU_Thread_Idle_body( uintptr_t ignored )
56798-{
56799-  while ( true ) {
56800-__asm__ volatile ("wfi");
56801-d040:bf30  wfi
56802-  }
56803:d042:e7fd  b.nd040 <_CPU_Thread_Idle_body>
56804-
56805-d044 :
56806-int rtems_filesystem_default_close(
56807-  rtems_libio_t *iop
56808-)
56809-{
56810-  return 0;
56811-}
56812-d044:2000  movsr0, #0
56813-d046:4770  bxlr


that's to say when i want to enter low power  i just need to call sleep or
rtems_task_wake_after or just while(1); ?

On Wed, Apr 24, 2019 at 4:36 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> For some reason your grep hasn't found the _CPU_Thread_Idle_body. It's
> possible that the stm32f4 uses some other function for that also I don't
> know why.
>
> For example for the xilinx_zynq_a9_qemu BSP the disassembled idle body
> looks like follows:
>
> void *_CPU_Thread_Idle_body( uintptr_t ignored )
> {
>11d70:   b480push{r7}
>11d72:   b083sub sp, #12
>11d74:   af00add r7, sp, #0
>11d76:   6078str r0, [r7, #4]
>   while ( true ) {
> #ifdef ARM_MULTILIB_HAS_WFI
> __asm__ volatile ("wfi");
>11d78:   bf30wfi
>11d7a:   e7fdb.n 11d78 <_CPU_Thread_Idle_body+0x8>
>
> Am 24.04.19 um 10:25 schrieb Jython:
> > arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto -n -B 5 -A
> 12
> >
> > there is no idle function which calls wfi command
> > // log
> > 508-
> > 509-
> > 510-
> > 511-}
> > 512-
> > 513:if((*USART2_SR) & (1<<4))  // idle
> > 514- 3aa:4b13  ldrr3, [pc, #76]; (3f8
> > )
> > 515- 3ac:681b  ldrr3, [r3, #0]
> > 516- 3ae:681b  ldrr3, [r3, #0]
> > 517- 3b0:f003 0310 and.wr3, r3, #16
> > 518- 3b4:2b00  cmpr3, #0
> > 519- 3b6:d00a  beq.n3ce 
> > 520-{
> > 521://printk("idle ");
> > 522-
> > 523-temp = (*USART2_SR);
> > 524- 3b8:4b0f  ldrr3, [pc, #60]; (3f8
> > )
> > 525- 3ba:681b  ldrr3, [r3, #0]
> > 526- 3bc:681b  ldrr3, [r3, #0]
> > 527- 3be:60fb  strr3, [r7, #12]
> > 528-temp = (*USART2_DR);
> > 529- 3c0:4b0f  ldrr3, [pc, #60]; (400
> > )
> > 530- 3c2:681b  ldrr3, [r3, #0]
> > 531- 3c4:681b  ldrr3, [r3, #0]
> > 532- 3c6:60fb  strr3, [r7, #12]
> > 533-//temp = temp;
> > --
> > 627-
> > 628-
> > 629-
> > 630-}
> > 631-
> > 632:if((*USART3_SR) & (1<<4))  // idle
> > 633- 44c:4b12  ldrr3, [pc, #72]; (498
> > )
> > 634- 44e:681b  ldrr3, [r3, #0]
> > 635- 450:681b  ldrr3, [r3, #0]
> > 636- 452:f003 0310 and.wr3, r3, #16
> > 637- 456:2b00  cmpr3, #0
> > 638- 458:d00a  beq.n470 
> > 639-{
> > 640://printk("idle ");
> > 641-
> > 642-temp = (*USART3_SR);
> > 643- 45a:4b0f  ldrr3, [pc, #60]; (498
> > )
> > 644- 45c:681b  ldrr3, [r3, #0]
> > 645- 45e:681b  ldrr3, [r3, #0]
> > 646- 460:60fb  strr3, [r7, #12]
> > 647-temp = (*USART3_DR);
> > 648- 462:4b0f  ldrr3, [pc, #60]; (4a0
> > )
> > 649- 464:681b  ldrr3, [r3, #0]
> > 650- 466:681b  ldrr3, [r3, #0]
> > 651- 468:60fb  strr3, [r7, #12]
> > 652-
> > --
> > 26329-
> > 26330-if (newTail == tty->rawOutBuf.Head) {
> > 26331-  /*
> > 26332-   * Buffer has become empty
> > 26333-   */
> > 26334:  tty->rawOutBufState = rob_idle;
> > 26335-69a0:f880 5094 strb.wr5, [r0, #148]; 0x94
> > 26336-  (*tty->handler.write) (ctx, NULL, 0);
> > 26337-69a4:f8d4 30c4 ldr.wr3, [r4, #196]; 0xc4
> > 26338-69a8:4670  movr0, lr
> > 26339-69aa:4629  movr1, r5
> > 26340-69ac:462a  movr2, r5
> > 26341-69ae:4798  blxr3
> > 26342-  nToSend = 0;
> > 26343-
> > 26344-  /*
> > 26345-   * check to see if snd wakeup callback was set
> > 26346-   */
> > --
> > 26443-6a12:2600  movsr6, #0
> > 26444-6a14:e7ac  b.n6970
> > 
> > 26445-  /*
> > 26446-   * Buffer has become empty
> > 26447-   */
> > 26448:  tty->rawOutBufState = rob_idle;
> > 26449-  (*tty->handler.write) (ctx, NULL, 0);
> > 26450-  nToSend = 0;
> > 26451-6a16:461d  movr5, r3
> > 26452-6a18:e7aa  b.n6970
> > 
> 

Re: stm32f4 __wfi

[Christian Mauderer]

For some reason your grep hasn't found the _CPU_Thread_Idle_body. It's
possible that the stm32f4 uses some other function for that also I don't
know why.

For example for the xilinx_zynq_a9_qemu BSP the disassembled idle body
looks like follows:

void *_CPU_Thread_Idle_body( uintptr_t ignored )
{
   11d70:   b480push{r7}
   11d72:   b083sub sp, #12
   11d74:   af00add r7, sp, #0
   11d76:   6078str r0, [r7, #4]
  while ( true ) {
#ifdef ARM_MULTILIB_HAS_WFI
__asm__ volatile ("wfi");
   11d78:   bf30wfi
   11d7a:   e7fdb.n 11d78 <_CPU_Thread_Idle_body+0x8>

Am 24.04.19 um 10:25 schrieb Jython:
> arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto -n -B 5 -A 12
> 
> there is no idle function which calls wfi command
> // log
> 508-       
> 509-       
> 510-               
> 511-    }
> 512-   
> 513:    if((*USART2_SR) & (1<<4))  // idle
> 514- 3aa:    4b13      ldr    r3, [pc, #76]    ; (3f8
> )
> 515- 3ac:    681b      ldr    r3, [r3, #0]
> 516- 3ae:    681b      ldr    r3, [r3, #0]
> 517- 3b0:    f003 0310     and.w    r3, r3, #16
> 518- 3b4:    2b00      cmp    r3, #0
> 519- 3b6:    d00a      beq.n    3ce 
> 520-    {
> 521:        //printk("idle ");
> 522-   
> 523-    temp = (*USART2_SR);
> 524- 3b8:    4b0f      ldr    r3, [pc, #60]    ; (3f8
> )
> 525- 3ba:    681b      ldr    r3, [r3, #0]
> 526- 3bc:    681b      ldr    r3, [r3, #0]
> 527- 3be:    60fb      str    r3, [r7, #12]
> 528-        temp = (*USART2_DR);
> 529- 3c0:    4b0f      ldr    r3, [pc, #60]    ; (400
> )
> 530- 3c2:    681b      ldr    r3, [r3, #0]
> 531- 3c4:    681b      ldr    r3, [r3, #0]
> 532- 3c6:    60fb      str    r3, [r7, #12]
> 533-    //temp = temp;
> --
> 627-       
> 628-       
> 629-               
> 630-    }
> 631-   
> 632:    if((*USART3_SR) & (1<<4))  // idle
> 633- 44c:    4b12      ldr    r3, [pc, #72]    ; (498
> )
> 634- 44e:    681b      ldr    r3, [r3, #0]
> 635- 450:    681b      ldr    r3, [r3, #0]
> 636- 452:    f003 0310     and.w    r3, r3, #16
> 637- 456:    2b00      cmp    r3, #0
> 638- 458:    d00a      beq.n    470 
> 639-    {
> 640:        //printk("idle ");
> 641-   
> 642-    temp = (*USART3_SR);
> 643- 45a:    4b0f      ldr    r3, [pc, #60]    ; (498
> )
> 644- 45c:    681b      ldr    r3, [r3, #0]
> 645- 45e:    681b      ldr    r3, [r3, #0]
> 646- 460:    60fb      str    r3, [r7, #12]
> 647-        temp = (*USART3_DR);
> 648- 462:    4b0f      ldr    r3, [pc, #60]    ; (4a0
> )
> 649- 464:    681b      ldr    r3, [r3, #0]
> 650- 466:    681b      ldr    r3, [r3, #0]
> 651- 468:    60fb      str    r3, [r7, #12]
> 652-   
> --
> 26329-
> 26330-    if (newTail == tty->rawOutBuf.Head) {
> 26331-  /*
> 26332-   * Buffer has become empty
> 26333-   */
> 26334:  tty->rawOutBufState = rob_idle;
> 26335-    69a0:    f880 5094     strb.w    r5, [r0, #148]    ; 0x94
> 26336-  (*tty->handler.write) (ctx, NULL, 0);
> 26337-    69a4:    f8d4 30c4     ldr.w    r3, [r4, #196]    ; 0xc4
> 26338-    69a8:    4670      mov    r0, lr
> 26339-    69aa:    4629      mov    r1, r5
> 26340-    69ac:    462a      mov    r2, r5
> 26341-    69ae:    4798      blx    r3
> 26342-  nToSend = 0;
> 26343-
> 26344-  /*
> 26345-   * check to see if snd wakeup callback was set
> 26346-   */
> --
> 26443-    6a12:    2600      movs    r6, #0
> 26444-    6a14:    e7ac      b.n    6970
> 
> 26445-  /*
> 26446-   * Buffer has become empty
> 26447-   */
> 26448:  tty->rawOutBufState = rob_idle;
> 26449-  (*tty->handler.write) (ctx, NULL, 0);
> 26450-  nToSend = 0;
> 26451-    6a16:    461d      mov    r5, r3
> 26452-    6a18:    e7aa      b.n    6970
> 
> 26453-    6a1a:    bf00      nop
> 26454-
> 26455-6a1c :
> 26456-
> 26457-/*
> 26458- * this task actually processes any transmit events
> 26459- */
> 26460-static rtems_task rtems_termios_txdaemon(rtems_task_argument argument)
> --
> 27083-  RTEMS_NO_PRIORITY,
> 27084-  >rawOutBuf.Semaphore);
> 27085-    if (sc != RTEMS_SUCCESSFUL)
> 27086-    6cc0:    2800      cmp    r0, #0
> 27087-    6cc2:    f040 80d6     bne.w    6e72
> 
> 27088:    tty->rawOutBufState = rob_idle;
> 27089-
> 27090-    /*
> 27091- * Set callbacks
> 27092- */
> 27093-    if (device_node != NULL) {
> 27094-    6cc6:    9b0e      ldr    r3, [sp, #56]    ; 0x38
> 27095-  RTEMS_SIMPLE_BINARY_SEMAPHORE | RTEMS_FIFO,
> 27096-  RTEMS_NO_PRIORITY,
> 27097-  >rawOutBuf.Semaphore);
> 27098-    if (sc != RTEMS_SUCCESSFUL)
> 27099-  rtems_fatal_error_occurred (sc);
> 27100:    tty->rawOutBufState = rob_idle;
> 

Re: stm32f4 __wfi

[Jython]

arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto -n -B 5 -A 12

there is no idle function which calls wfi command
// log
508-
509-
510-
511-}
512-
513:if((*USART2_SR) & (1<<4))  // idle
514- 3aa:4b13  ldrr3, [pc, #76]; (3f8
)
515- 3ac:681b  ldrr3, [r3, #0]
516- 3ae:681b  ldrr3, [r3, #0]
517- 3b0:f003 0310 and.wr3, r3, #16
518- 3b4:2b00  cmpr3, #0
519- 3b6:d00a  beq.n3ce 
520-{
521://printk("idle ");
522-
523-temp = (*USART2_SR);
524- 3b8:4b0f  ldrr3, [pc, #60]; (3f8
)
525- 3ba:681b  ldrr3, [r3, #0]
526- 3bc:681b  ldrr3, [r3, #0]
527- 3be:60fb  strr3, [r7, #12]
528-temp = (*USART2_DR);
529- 3c0:4b0f  ldrr3, [pc, #60]; (400
)
530- 3c2:681b  ldrr3, [r3, #0]
531- 3c4:681b  ldrr3, [r3, #0]
532- 3c6:60fb  strr3, [r7, #12]
533-//temp = temp;
--
627-
628-
629-
630-}
631-
632:if((*USART3_SR) & (1<<4))  // idle
633- 44c:4b12  ldrr3, [pc, #72]; (498
)
634- 44e:681b  ldrr3, [r3, #0]
635- 450:681b  ldrr3, [r3, #0]
636- 452:f003 0310 and.wr3, r3, #16
637- 456:2b00  cmpr3, #0
638- 458:d00a  beq.n470 
639-{
640://printk("idle ");
641-
642-temp = (*USART3_SR);
643- 45a:4b0f  ldrr3, [pc, #60]; (498
)
644- 45c:681b  ldrr3, [r3, #0]
645- 45e:681b  ldrr3, [r3, #0]
646- 460:60fb  strr3, [r7, #12]
647-temp = (*USART3_DR);
648- 462:4b0f  ldrr3, [pc, #60]; (4a0
)
649- 464:681b  ldrr3, [r3, #0]
650- 466:681b  ldrr3, [r3, #0]
651- 468:60fb  strr3, [r7, #12]
652-
--
26329-
26330-if (newTail == tty->rawOutBuf.Head) {
26331-  /*
26332-   * Buffer has become empty
26333-   */
26334:  tty->rawOutBufState = rob_idle;
26335-69a0:f880 5094 strb.wr5, [r0, #148]; 0x94
26336-  (*tty->handler.write) (ctx, NULL, 0);
26337-69a4:f8d4 30c4 ldr.wr3, [r4, #196]; 0xc4
26338-69a8:4670  movr0, lr
26339-69aa:4629  movr1, r5
26340-69ac:462a  movr2, r5
26341-69ae:4798  blxr3
26342-  nToSend = 0;
26343-
26344-  /*
26345-   * check to see if snd wakeup callback was set
26346-   */
--
26443-6a12:2600  movsr6, #0
26444-6a14:e7ac  b.n6970

26445-  /*
26446-   * Buffer has become empty
26447-   */
26448:  tty->rawOutBufState = rob_idle;
26449-  (*tty->handler.write) (ctx, NULL, 0);
26450-  nToSend = 0;
26451-6a16:461d  movr5, r3
26452-6a18:e7aa  b.n6970

26453-6a1a:bf00  nop
26454-
26455-6a1c :
26456-
26457-/*
26458- * this task actually processes any transmit events
26459- */
26460-static rtems_task rtems_termios_txdaemon(rtems_task_argument argument)
--
27083-  RTEMS_NO_PRIORITY,
27084-  >rawOutBuf.Semaphore);
27085-if (sc != RTEMS_SUCCESSFUL)
27086-6cc0:2800  cmpr0, #0
27087-6cc2:f040 80d6 bne.w6e72

27088:tty->rawOutBufState = rob_idle;
27089-
27090-/*
27091- * Set callbacks
27092- */
27093-if (device_node != NULL) {
27094-6cc6:9b0e  ldrr3, [sp, #56]; 0x38
27095-  RTEMS_SIMPLE_BINARY_SEMAPHORE | RTEMS_FIFO,
27096-  RTEMS_NO_PRIORITY,
27097-  >rawOutBuf.Semaphore);
27098-if (sc != RTEMS_SUCCESSFUL)
27099-  rtems_fatal_error_occurred (sc);
27100:tty->rawOutBufState = rob_idle;
27101-6cc8:f884 0094 strb.wr0, [r4, #148]; 0x94
27102-
27103-/*
27104- * Set callbacks
27105- */
27106-if (device_node != NULL) {
27107-6ccc:2b00  cmpr3, #0
27108-6cce:f000 80e9 beq.w6ea4

27109-  device_node->tty = tty;
27110-  tty->handler = *device_node->handler;
27111-6cd2:f104 0cb8 add.wip, r4, #184; 0xb8
27112-6cd6:4666  movr6, ip
--
29226-  /* disable interrupts*/
29227-  rtems_termios_device_lock_acquire (ctx, _context);
29228-  tty->flow_ctrl &= ~FL_OSTOP;
29229-7442:f8d4 30d8 ldr.wr3, [r4, #216]; 0xd8
29230-  /* check for chars in output buffer (or rob_state?) */
29231:  if (tty->rawOutBufState != rob_idle) {
29232-7446:f894 2094 ldrb.wr2, [r4, #148]; 0x94
29233-
29234-/* has output been stopped due to received XOFF? */
29235-if (tty->flow_ctrl & FL_OSTOP) {
29236-  /* disable interrupts*/
29237-  

Re: stm32f4 __wfi

[Christian Mauderer]

Am 24.04.19 um 02:35 schrieb Jython:
> yes, I need to do low power for stm32f4
> will this line work __asm__ volatile ("wfi");?

That line should be correct. Please note that the instruction is already
used in the armv7 idle thread:

https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/armv7-thread-idle.c#n32

The stm32f4 is a Cortex-M4 so it's quite likely that this routine is
used. You can check by doing an "arm-rtems5-objdump -dS" on your file
and search for the idle body.

With kind regards

Christian

> 
> 
> On Tue, Apr 23, 2019 at 10:28 PM Christian Mauderer
>  > wrote:
> 
> Am 22.04.19 um 09:47 schrieb Jython:
> > HI, ALL!
> > wfi
> http://www.keil.com/support/man/docs/armcc/armcc_chr1359125004400.htm
> > how can i call the arm __wfi?
> >
> > ___
> > users mailing list
> > users@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/users
> >
> 
> Hello Jython,
> 
> WFI is an assembler instruction. The Keil wrapper isn't available in
> gcc. I know of no direct replacement. Most likely you need a gcc inline
> assembly for that.
> 
> May I ask why you would need "wfi"? If you use a operating system, the
> system typically handles such low level stuff for you. The only
> application that springs to mind for that instruction is overwriting the
> idle loop to save energy.
> 
> Best regards
> 
> Christian
> 
> -- 
> 
> 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.
> 

-- 

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

Re: stm32f4 __wfi

[Jython]

yes, I need to do low power for stm32f4
will this line work __asm__ volatile ("wfi");?


On Tue, Apr 23, 2019 at 10:28 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 22.04.19 um 09:47 schrieb Jython:
> > HI, ALL!
> > wfi
> http://www.keil.com/support/man/docs/armcc/armcc_chr1359125004400.htm
> > how can i call the arm __wfi?
> >
> > ___
> > users mailing list
> > users@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> Hello Jython,
>
> WFI is an assembler instruction. The Keil wrapper isn't available in
> gcc. I know of no direct replacement. Most likely you need a gcc inline
> assembly for that.
>
> May I ask why you would need "wfi"? If you use a operating system, the
> system typically handles such low level stuff for you. The only
> application that springs to mind for that instruction is overwriting the
> idle loop to save energy.
>
> Best regards
>
> Christian
>
> --
> 
> 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

Re: stm32f4 __wfi

[Christian Mauderer]

Am 22.04.19 um 09:47 schrieb Jython:
> HI, ALL!
> wfi http://www.keil.com/support/man/docs/armcc/armcc_chr1359125004400.htm
> how can i call the arm __wfi?
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

Hello Jython,

WFI is an assembler instruction. The Keil wrapper isn't available in
gcc. I know of no direct replacement. Most likely you need a gcc inline
assembly for that.

May I ask why you would need "wfi"? If you use a operating system, the
system typically handles such low level stuff for you. The only
application that springs to mind for that instruction is overwriting the
idle loop to save energy.

Best regards

Christian

-- 

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