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
  • Maybe not a useful question, but if you don't spit out the debug message, do you still see the high current draw? I'm not sure how the UART is configured, but perhaps it is being left in the ON state before going back to sleep.

    In general, the implementation seems OK to me. Since this code is interfacing with a switch, it will need some debouncing on the input also. Otherwise, the interrupt will trigger multiple times if the input bounces (although, it looks like the code handles the interrupt in the scheduler; I'm not sure where it gets reenabled or if it gets reenabled).

Reply
  • Maybe not a useful question, but if you don't spit out the debug message, do you still see the high current draw? I'm not sure how the UART is configured, but perhaps it is being left in the ON state before going back to sleep.

    In general, the implementation seems OK to me. Since this code is interfacing with a switch, it will need some debouncing on the input also. Otherwise, the interrupt will trigger multiple times if the input bounces (although, it looks like the code handles the interrupt in the scheduler; I'm not sure where it gets reenabled or if it gets reenabled).

Children
No Data
Related