This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

current consumption increases after first GPIOTE interrupt

I have a problem with some current consumption I cannot explain. I first thought it had something to do with floating pins or something, but that does not seem to be the case.

The problem boils down to this: after startup, I configure pins, and. among other things, I configure the GPIOTE, to generate a port interrupt, and enable 2 pins which are connected to a switch. When I then go to low power, all is fine, current consumption is about 20 uA (I have some peripherals on my board, so the 20 uA is as expected).

However, when I receive a first GPIOTE interrupt, when pressing a button, my current consumption increases to about 600 uA. I really cannot figure out what I am doing wrong. The only thing is that, when I disable the GPIOTE interrupt, but still operate everything else, like timers and such, the sleep mode current stays at around 20 uA.

Is there something in a GPIOTE interrupt that keeps something awake in the chip? Can anyone give me a hint of what might be wrong?

BTW: I am not using the app_gpiote library, I wrote my own, much more limited version. Maybe I need to reset something in my interrupt routine, I do not know. Any ideas are welcome.

Parents
  • the DBG is just a macro around the SEGGER_RTT_printf function, so no UART involved. But even when it is redefined to nothing, so no printf is done, power consumption is too high.

    And about the re-enable: in the scheduler, at the end of the interrupt handler call back function, I do:

    gpiote_enable_port_interrupt();
    

    Also, the interrupt is de-bounced using a single shot timer which gets restarted when the input signal is bouncing. In the hardware there is also a low-pass filter to debounce the signal.

Reply
  • the DBG is just a macro around the SEGGER_RTT_printf function, so no UART involved. But even when it is redefined to nothing, so no printf is done, power consumption is too high.

    And about the re-enable: in the scheduler, at the end of the interrupt handler call back function, I do:

    gpiote_enable_port_interrupt();
    

    Also, the interrupt is de-bounced using a single shot timer which gets restarted when the input signal is bouncing. In the hardware there is also a low-pass filter to debounce the signal.

Children
No Data
Related