nRF52832 Timer Enable Disable Fails Assert and Hard Faults

[edmcnicholas]

I am having an issue where i use a GPIO pin to start and stop a timer based on device state and a GPIOE toggle event.  The issue i am seeing is that nrf_drv_timer_enable and nrf_drv_timer_disable randomly fail assert and this is causing a hard fault.  I need this timer to start and stop so that i can get to lowest connected power states when it is not needed.  I cant see a really good reason for this to be happening so any help would be appreciated.  Below is the code.

void MilesWakeHandler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    uint8_t fret = EXIT_SUCCESS;
    /* Get Pin Value */
    uint32_t sense = nrf_gpio_pin_read(UTA_MILES_WAKE);
    if(sense == 1)
    {
        //NRF_LOG_DEBUG("Miles Wake High");
        nrf_drv_timer_enable(&m_timer1);        //Start Timer
        //TODO request timeslot if needed
    }
    else if (sense == 0)
    {
        nrf_drv_timer_disable(&m_timer1);     //Stop Timer
        nrf_drv_timer_clear(&m_timer1);       //Clear Timer
        //NRF_LOG_DEBUG("Miles Wake Low");
        appMiles_ProcessHits();
        //TODO stop timeslot if needed
        //app_sched_event_put(NULL, 0, (app_sched_event_handler_t)MilesSleep);
    }
    
}

[AmbystomaLabs]

You don't say what the min and max of the timer interval is.  A common mistake is to exercise the timers in ISR's which are inherently delayed and sometime lost if you don't prepare properly for the event in code.

Since all you do is start and stop a timer based on gpio, you should have all that done in ppi/gpiote instead of pulling it out to an interrrupt.  The ppi/gpiote can be configured such that a pin assert drives timer events.  

Just remember the min timer time is 2 pclk's. 

[edmcnicholas]

This does not work if i need a GPIO to execute one event on high and one on low there seems to be a disconnect in the api for this type of behavior.

[AmbystomaLabs]

In addition to what I wrote above, this seemed relevant: https://devzone.nordicsemi.com/f/nordic-q-a/32566/gpiote-missing-event/125379#125379

[AmbystomaLabs]

So to further explain it, you rely on a pin read to establish what you should do.  Depending on the latency maybe that is true, maybe not.  At any one time there should be only one IRQ tied to this function and one system event.

Likely things just get out of sync.

By moving all the start/stop to ppi.  Your software event can focus on something always true which is to tally.  You may have to figure out a way to keep the timer from proceeding until you tally.  Just in case the pin is just getting hammered repeatedly without time for you to deal with it.