How to differentiate which GPIO causing device to wake-up from System OFF

[beemavishnu]

Hello,

 

I am using nRF52832, SDK_15.3.0, S132 SoftDevice and Segger for flashing the image. I am using ‘ble_app_blinky’.

RESETREAS will give cause of reset. But for System OFF, is there any option to determine which GPIO causes device to wake-up from System OFF mode.

 

Thanks & Regards

Vishnu Beema

[Håkon Alseth]

Hi,

 

You can read out the GPIO LATCH register on boot up:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpio.html?cp=3_1_0_19_2_7#register.LATCH

 

Note that this is a cumulative register, meaning that you need to clear it after reading.

 

Kind regards,

Håkon

[beemavishnu]

Hello,

I am using Segger and testing over nRF52832 development kit.

Below is the code I implemented. I configure two pins to wake-up from System off mode (For example P0.13 and P0.14 in ble_app_blinky)

Sequence 1 (Press same button repeatedly)

1) Press button 1(P0.13) repeatedly. Always I will get 'latch 13'. 

2) Since LATCH register is cleared, if I press button 2 (P0.14) repeatedly I am seeing 'latch 14' only. 

3) If I don't clear LATCH register, even though I press button 2 (P0.14) I keep getting both 'latch 13' and 'latch 14'.

So sequence 1 worked fine for me.

Sequence 2 (Press buttons alternatively)

1) For first time if I press button 1 (P0.13) it will show only 'latch 13'.

2) But after System OFF, if I press button 2 (P0.14) rather than button 1 (P0.13) I am getting both P0.13 and P0.14 for first time.

3) Again if I press button 2 (P0.14) I am getting only 'latch 14' (Similar to Sequence 1).

My query are

1) Though LATCH register is cleared, why both pins are detected when they are pressed alternatively.

2) All above scenarios are without debugger connect. If I connect debugger, though I press button 1 (P0.13) repeatedly, still it shows both 'latch 13' and 'latch 14'. I am not sure why in debug mode.

To cross check, you can keep below code as is and test. Am I missing anything.

    uint32_t i;
    bool bPinLatch;
    
    for(i = 0; i < 32; i++)
    {
        // NRF_GPIO->LATCH // To identify the cause of Wakeup
        bPinLatch = nrf_gpio_pin_latch_get(i);
        
        if(bPinLatch == 1)
        {
            // The LATCH register will only be cleared if the CPU explicitly clears it by writing a '1'
            // to the bit that shall be cleared.
            nrf_gpio_pin_latch_clear(i);
            NRF_LOG_INFO("latch %d", i);
        }
    }

Thanks & Regards

Vishnu Beema

[Håkon Alseth]

Hi Vishnu,

 

Could it be due to the pin still being active when entering this loop?

Could you try adding a simple debounce routine prior to handling the LATCH to see if the issue still occurs?

// Simple Debounce
while (nrf_gpio_pin_read(13) == 0 || nrf_gpio_pin_read(14) == 0);

 

Kind regards,

Håkon

[beemavishnu]

Hi,

After calling nrf_gpio_pin_latch_clear(), if I call nrf_gpio_pin_latch_get() I am still getting output as 1. Is this expected.

    uint32_t i, j;
    bool bPinLatch;
    
    for(i = 0; i < 32; i++)
    {
        // NRF_GPIO->LATCH // To identify the cause of Wakeup
        bPinLatch = nrf_gpio_pin_latch_get(i);
        
        if(bPinLatch == 1)
        {
            // The LATCH register will only be cleared if the CPU explicitly clears it by writing a '1'
            // to the bit that shall be cleared.
            nrf_gpio_pin_latch_clear(i);
            j = nrf_gpio_pin_latch_get(i);
            
            NRF_LOG_INFO("latch %d %d", i, j);
        }
    }

Thanks & Regards

Vishnu Beema

[Håkon Alseth]

We have an errata on the LATCH wrt. clear/reading the register:

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_173.html?cp=3_1_1_0_1_43

 

Could you try forcing a wait cycle, for instance by adding nop's or reading a peripheral event, like "(void)NRF_TIMER1->EVENTS_COMPARE[0];" ?

 

Kind regards,

Håkon