GPIO interrupt after wake up

[gercer]

Hello

My custom board has only 1 button and I'm trying to detect 3 button clicks. The first click is waking up the device and the other 2 are configured as BSP_EVENT_KEY_0.  I noticed people pushes the button between 0.2s to 0.4s after each click and the nRF52832 is not detecting the second click and the button has to be pressed a 4th time.

The IRQ prority is already at 2. I´m not sure if I should put it higher. My guess is that something in the main has higher priority and it is ignoring the bsp event

The only problem i have is when the device is sleeping. When the device is advertising the interruptions work fine. Any idea what is happening?

Here is my main, 

 

int main(void)
 {
    bool       wakeup;

    ret_code_t err_code;

    log_init();

    // Initialize the async SVCI interface to bootloader before any interrupts are enabled.
    err_code = ble_dfu_buttonless_async_svci_init();
    APP_ERROR_CHECK(err_code);

    timers_init();
    buttons_leds_init(&wakeup);
    my_fstorage_init();
    if(wakeup)
    {
        timer_counter();
    }
    power_management_init();
    fstorage_read(0x66C00,4);
    
    ble_stack_init();
    peer_manager_init();
    gap_params_init();
    gatt_init();
    services_init(); 
    conn_params_init();
    advertising_init();
    
    //saadc init
    saadc_init();
    saadc_sampling_event_init();
    saadc_sampling_event_enable();
    
    adv_init_and_start();

    NRF_LOG_INFO("GWi DFU Application started.");
    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}

SDK15.2

nrf52832 custom board

nrf52DK

windows 10

segger v4.16

[haakonsh]

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. 

[gercer]

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.

[gercer]

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?

[gercer]

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

[haakonsh]

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? 

[gercer]

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

[haakonsh]

And what's the capacitance of the loading caps? 

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

[gercer]

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...

[haakonsh]

"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? 

[gercer]

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.

[haakonsh]

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.

[gercer]

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.