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]

Thank you for the information and i will have to make sure i have channels left .  I also need the GPIO event to trigger my processing function.  Should i use PPI to control the clock and the interrupt to run the function?  Also the gpio is driven by a time controlled circuit so the fastest it goes is 3.3mS.

[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]

It's not clear if you are using the gpiote driver or just registering system events with the SD.

Either way difficulties can arise.  During normal operation the BLE stack will lock out the processor for anything related to your code.  Just an advertisement can keep you locked out for nearly 1 msec.  During this time ISR's can accumulate and perhaps the original state is there and perhaps not.  There are only so many vectors on the NVIC and they need to play games keeping track of the events that need to be serviced.

Plus a msec here and there will give you a lot of random latency on your event timing.

You might be better off working it directly with the gpiote driver and using pin events. Since you said you need to do something on assert.  It may be unavoidable to do everything in an ISR. However, looking at your code it seems that you just start the timer on assert and then when button is released (or something) you tally the events.

Better to let the PPI/GPIOTE handle the start/stop of the timer, then you can always use a soft event on timer completion for your process_hits. This way latency doesn't matter.  You can put the timer clear either in the event handler or let the ppi do it via a fork or shorts.

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