GPIO interrupt after wake up

RE: GPIO interrupt after wake up

gercer — Fri, 03 Apr 2020 18:15:32 GMT

Keeping the device awake consumes too much battery so I decided to go back and try to fix the issue with nrf_sdh_enable.
Defining NRF_SDH_CLOCK_LF_SRC as NRF_CLOCK_LF_SRC_RC
or NRF_CLOCK_LF_SRC_XTAL takes a lot of time for nrf_sdh_enable to resolve. Using NRF_CLOCK_LF_SRC_SYNTH executes it faster. I don´t know why. For now I will just keep it like this. Thank you for the help.

RE: GPIO interrupt after wake up

haakonsh — Mon, 17 Feb 2020 10:29:41 GMT

Use nrf_pwr_mgmt_run(); instead. It will put the system into SystemON, Idle. And it will not reset the MCU when it wakes up.

RE: GPIO interrupt after wake up

gercer — Fri, 14 Feb 2020 18:51:30 GMT

Sorry that it took me a couple of months to reply.

static void sleep_mode_enter(void)
{

    uint32_t err_code = bsp_indication_set(BSP_INDICATE_IDLE);
    APP_ERROR_CHECK(err_code);
    bsp_led_state = BSP_INDICATE_IDLE;

    // Prepare wakeup buttons.
    err_code = bsp_btn_ble_sleep_mode_prepare();
    APP_ERROR_CHECK(err_code);

    //Disable SoftDevice. It is required to be able to write to GPREGRET2 register (SoftDevice API blocks it).
    //GPREGRET2 register holds the information about skipping CRC check on next boot.
    err_code = nrf_sdh_disable_request();
    APP_ERROR_CHECK(err_code);

    // Go to system-off mode (this function will not return; wakeup will cause a reset).
    err_code = sd_power_system_off();
    APP_ERROR_CHECK(err_code);
    
}

the reference manual says the default is system ON. I'm not sure where to change that.

RE: GPIO interrupt after wake up

haakonsh — Mon, 04 Nov 2019 12:57:24 GMT

"Oh, looks like we are using 12pF capacitors for both crystals, 32MHz and 32kHz."
The LFXO will operate with 12pF capacitors, but the accuracy might be way off and think you'll get a slight increase in current consumption.

I suggest you toggle a pin from the RTC peripheral once a second and measure the accuracy with a logic analyzer.

"But the problem can also be replicated in the nrf52 that´s why i dont´think the capacitors are the issue here..."
You're probably right.

What I think is happening is that the SoftDevice has to wait for the LFXO clock to stabilize, which takes ~250ms, and that somehow bodges stuff up for the app_timer library.

Do you use SystemOFF or SystemON for sleep?

RE: GPIO interrupt after wake up

gercer — Thu, 31 Oct 2019 22:34:13 GMT

Oh, looks like we are using 12pF capacitors for both crystals, 32MHz and 32kHz. But the problem can also be replicated in the nrf52 that´s why i dont´think the capacitors are the issue here...

RE: GPIO interrupt after wake up

haakonsh — Wed, 30 Oct 2019 11:56:52 GMT

And what's the capacitance of the loading caps?

With a 9pF crystal, you'll need 15pF loading capacitors.

RE: GPIO interrupt after wake up

gercer — Mon, 28 Oct 2019 20:25:34 GMT

Hi!

Yes here is the link of the datasheet and the capacitance is 9pF

https://www.sii.co.jp/en/quartz/files/2013/03/SC-20S_Leaflet_e20151217.pdf

RE: GPIO interrupt after wake up

haakonsh — Mon, 28 Oct 2019 10:39:58 GMT

Oh, there might be an issue with your external 32kHz crystal.

Can you share the part number for the 32kHz crystal and the capacitance of the loading caps you're using?

RE: GPIO interrupt after wake up

gercer — Wed, 23 Oct 2019 16:34:05 GMT

This is resolving the issue

#define NRF_SDH_CLOCK_LF_SRC 0 // I was using 32MHz XTAL
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

How will this affect the nRF52 behaviour?

Thanks

RE: GPIO interrupt after wake up

gercer — Fri, 18 Oct 2019 20:46:16 GMT

Hello,
I posted the code as private. Evn tho i don´t think it is necessary for you to check it. I think i found the problem. After doing some changes I left the main with the following fucntions:

log_init();
timers_init();
buttons_leds_init(&wakeup);
ble_stack_init();

After doing some research i found out the issue is the nrf_sdh_enable_request takes too long executing. Sadly the guy didnt post how he solved it. Do you have any idea what is going on?

RE: GPIO interrupt after wake up

haakonsh — Fri, 11 Oct 2019 11:16:54 GMT

Hmm, my best guess is that something is blocking the CPU from executing. Maybe the starting of the LFXO as it can take a few hundred ms.

Do you mind sharing a project that we can use to recreate your issue?
I suggest you strip out seemingly unrelated part of your code until the issue disappears as that will help us narrow down where the issue originates.

RE: GPIO interrupt after wake up

gercer — Thu, 10 Oct 2019 19:55:14 GMT

Sorry for the late reply,

It doesnt seem to be the problem because once the device is awake I can press the button as fast as i can and it detects every single click. The issue is just the first half second after waking up.

RE: GPIO interrupt after wake up

haakonsh — Tue, 10 Sep 2019 09:26:36 GMT

The BSP uses the app_button library who has implemented SW debouncing by setting an app_timer to trigger a callback after 50ms where the app_button library will check to see if the button is still pressed.
If the pin event is triggered before the 50ms has expired the app_button library will reset the app_timer. This might cause you trouble if the button signal is extremely bouncy.

I would scope the button signal to check for noise issues and log the button press patterns of good vs bad operations. This will give us valuable insight into how the application responds to the button presses.