RE: samples/hello no output on BBB

[Lou Woods]

Hello all,

To make sure something isn’t horribly broken in RTEMS with regards to the BBB, 
I ran the RTEMS test suite on the BBB and it seems to work as expected.  Out of 
597 tests 572 tests passed including hello.exe.   This is the latest RTEMS 5 
build tree.

I don’t have any experience with rtems-boot-image unfortunately so I’m not much 
help there.  I used objcopy and mkimage to create an image loadable on U-boot 
via tftp.

For what it’s worth this is the configure line I used:
  $ ../rtems/configure --target=arm-rtems5 --enable-rtemsbsp=beagleboneblack 
--prefix=/home/labtester/test/ATF/bsp-install/ --enable-networking 
--enable-posix --disable-smp --disable-multiprocessing --enable-tests 
--enable-cxx --enable-maintainer-mode

Lou

From: users  On Behalf Of Nils Hölscher
Sent: Friday, June 21, 2019 4:03 AM
To: users@rtems.org; chr...@rtems.org
Subject: samples/hello no output on BBB

Hi,

I make bootable SD-image for the BBB with Chris tool:
$ rtems-boot-image -o sd-card.img -b u-boot-beaglebone -s 32m -k hello.exe 
u-boot/MLO u-boot/u-boot.img

When I boot with serial connected I get the following output:
"
Booting kernel from Legacy Image at 8200 ...
Image Name:   RTEMS
Created:  2019-06-17   8:03:14 UTC
Image Type:   ARM Linux Kernel Image (gzip compressed)
Data Size:48801 Bytes = 47.7 KiB
Load Address: 8000
Entry Point:  8000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...
"

But the Hello world prints are missing.
The board just restarts after a few minutes.
Can anyone help me, please?

I attached my config log from samples.

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

Re: RISC-V Support for HiFive Unleashed

[Sachin Ghadi]

On Wed, Jun 12, 2019 at 6:00 PM Sebastian Huber
 wrote:
>
> On 11/06/2019 20:53, Molock, Dwaine S. (GSFC-5820) wrote:
> > All:
> >
> > Does the current RTEMS RISC-V port support the HiFive Unleashed
> > (https://www.sifive.com/boards/hifive-unleashed) development board?
>
> If it is similar to the Qemu platform, then it should work.  The complex
> drivers may be available via libbsd from FreeBSD.
>
> >
> > If not, what BSP should I use as a starting point to create a BSP for
> > this particular board?  Is there a generic RISC-V BSP I could use?
>
> Yes, use this BSP:
>
> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html#riscv

For Hifive Unleashed there is no BSP but RISCV core port is available as above .
I am in process of releasing one port for E series cores based SoC from Sifive.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> 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



-- 
Thanks and Regards,
Sachin Ghadi
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

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 

samples/hello no output on BBB

[Nils Hölscher]

Hi,

I make bootable SD-image for the BBB with Chris tool:
$ rtems-boot-image -o sd-card.img -b u-boot-beaglebone -s 32m -k hello.exe
u-boot/MLO u-boot/u-boot.img

When I boot with serial connected I get the following output:
"
Booting kernel from Legacy Image at 8200 ...
Image Name:   RTEMS
Created:  2019-06-17   8:03:14 UTC
Image Type:   ARM Linux Kernel Image (gzip compressed)
Data Size:48801 Bytes = 47.7 KiB
Load Address: 8000
Entry Point:  8000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...
"

But the Hello world prints are missing.
The board just restarts after a few minutes.
Can anyone help me, please?

I attached my config log from samples.

Best,
Nils
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by rtems-c-src-tests-samples configure 5.0.0, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ../../../../../../rtems/c/src/../../testsuites/samples/configure --disable-option-checking --prefix=/home/nils/development/5 --host=arm-rtems5 --build=x86_64-pc-linux-gnu --target=arm-rtems5 --enable-tests --enable-posix --with-target-subdir=arm-rtems5 --exec-prefix=/home/nils/development/5/arm-rtems5 --includedir=/home/nils/development/5/arm-rtems5/include build_alias=x86_64-pc-linux-gnu host_alias=arm-rtems5 target_alias=arm-rtems5 --with-project-root=../../ --with-project-top=../../ --with-rtems-build-top=/home/nils/development/kernel/beagleboneblack/arm-rtems5/c/beagleboneblack --with-rtems-source-top=/home/nils/development/kernel/rtems RTEMS_BSP=beagleboneblack RTEMS_BSP_FAMILY=beagle CFLAGS=-mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs --enable-rtems-root=../ --enable-project-root=../../../beagleboneblack --with-project-top=../../../ --enable-rtemsbsp=beagleboneblack --includedir=/home/nils/development/5/arm-rtems5/beagleboneblack/lib/include --libdir=/home/nils/development/5/arm-rtems5/beagleboneblack/lib --cache-file=/dev/null --srcdir=../../../../../../rtems/c/src/../../testsuites/samples

## - ##
## Platform. ##
## - ##

hostname = nils-Laptop
uname -m = x86_64
uname -r = 5.1.11-arch1-1-ARCH
uname -s = Linux
uname -v = #1 SMP PREEMPT Mon Jun 17 18:56:30 UTC 2019

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/nils/development/5/bin
PATH: /home/nils/development/5/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /usr/lib/jvm/default/bin
PATH: /usr/bin/site_perl
PATH: /usr/bin/vendor_perl
PATH: /usr/bin/core_perl


## --- ##
## Core tests. ##
## --- ##

configure:2075: checking for gmake
configure:2105: result: no
configure:2075: checking for make
configure:2091: found /usr/bin/make
configure:2102: result: make
configure:2211: checking build system type
configure:2225: result: x86_64-pc-linux-gnu
configure:2245: checking host system type
configure:2258: result: arm-unknown-rtems5
configure:2279: checking rtems target cpu
configure:2290: result: arm
configure:2316: checking for a BSD-compatible install
configure:2384: result: /usr/bin/install -c
configure:2395: checking whether build environment is sane
configure:2450: result: yes
configure:2507: checking for arm-rtems5-strip
configure:2523: found /home/nils/development/5/bin/arm-rtems5-strip
configure:2534: result: arm-rtems5-strip
configure:2599: checking for a thread-safe mkdir -p
configure:2638: result: /usr/bin/mkdir -p
configure:2645: checking for gawk
configure:2661: found /usr/bin/gawk
configure:2672: result: gawk
configure:2683: checking whether make sets $(MAKE)
configure:2705: result: yes
configure:2774: checking whether to enable maintainer-specific portions of Makefiles
configure:2783: result: no
configure:2815: checking for RTEMS_BSP
configure:2827: result: beagleboneblack
configure:2856: checking for style of include used by make
configure:2884: result: GNU
configure:2920: checking for arm-rtems5-gcc
configure:2936: found /home/nils/development/5/bin/arm-rtems5-gcc
configure:2947: result: arm-rtems5-gcc
configure:2966: checking for arm-rtems5-gcc
configure:2993: result: arm-rtems5-gcc
configure:3262: checking for C compiler version
configure:3271: arm-rtems5-gcc --version >&5
arm-rtems5-gcc (GCC) 7.4.1 20190514 (RTEMS 5, RSB 1db8e0cbd7eeaa904449d4bb4faa88879c694f2f-modified, Newlib 1d35a003f)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3282: $? = 0
configure:3271: arm-rtems5-gcc -v >&5
Using 

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);
> >