low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

[WolfgangEbersbach]

Dear all,

I need to measure a pulse width on a GPIO pin which is in between 100mseconds and 7.2 seconds long without the use of "regular" timers due to low power requirements. I am pretty sure this can be done with PPI and the 32.768 kHz lfclock ( which runs anyway due to S210 use ). But I am simply lost in the examples and driver docs. Especially as I base my work on the bikepower ANT+ example which uses the board support package and app_button. Due to this I cannot copy-paste any code example as this always conflicts with something in the BSP or app_button.

Is there a hint which drivers / app_whatever to "implement" into existing examples that use BSP and app_button to connect a GPIO via PPI to a lsclock counter/timer ?

I "simply" need to start a lsclock counter by a GPIO pin interrupt (Low-High) and stop it by a high-low interrupt. Sadly I seem to be unable to do implement this simple task into the existing example code. As my max pulsewidth is > 10 seconds, a 16 bit counter is not sufficient @ 32.768 kHz clock. I am not sure if I can handle timer overflows due to the softdevice interrupting my program at any time.

Anyhow, the RealTimeCounter is 24 bits which is enough for my purpose. So, with RTC prescaler = 0 ( as used in app_button like it seems..) I could store the current TICK count at the low-high interrupt and then compare to the TICK count at the high-low interrupt and that's it. The counter roll-over case could be handled outside the ISR.

Just: How to do it ?

Any help like "remove this driver, add that one, re-use this timer.. " is very appreciated.

Thanks a lot, Wolfgang

[Ole Bauck]

It works when setting the accuracy to high, GPIOTE_CONFIG_IN_SENSE_LOTOHI(true), strange...

[WolfgangEbersbach]

It does NOT work for me with high accuracy. Note: not the nrf_drv_gpiote_in_init crashes the application. The subsequent APP_ERROR_CHECK does. So far I was not able to find out what APP_ERROR_CHECK does. It points to a function ( via a macro pointing to a macro pointing to a function ... ) that to me seem just to copy some parameters to new variables with a m_ prefix and then go to an infinite loop ?? On the debugger screenshot below you can see that "err_code" is "out of scope" ?

[Ole Bauck]

I will not get an answer before tomorrow. When it comes to gpiote, you may be better off using the registers and not the SDK. This code will setup a pin for SENSING and enable the PORT event interrupt:

NRF_GPIO->PIN_CNF[BSP_BUTTON_0] =   (GPIO_PIN_CNF_DIR_Input << GPIO_PIN_CNF_DIR_Pos)
                                    |(GPIO_PIN_CNF_INPUT_Connect << GPIO_PIN_CNF_INPUT_Pos)
                                    |(GPIO_PIN_CNF_PULL_Pullup << GPIO_PIN_CNF_PULL_Pos)
                                    |(GPIO_PIN_CNF_SENSE_Low << GPIO_PIN_CNF_SENSE_Pos);

NRF_GPIOTE->INTENSET = (GPIOTE_INTENSET_PORT_Enabled << GPIOTE_INTENSET_PORT_Pos);

NVIC_EnableIRQ(GPIOTE_IRQn);

The interrupt code will be like this:

void GPIOTE_IRQHandler(void)
{
    if((NRF_GPIOTE->EVENTS_PORT == 1) &&
        ((NRF_GPIOTE->INTENSET & GPIOTE_INTENSET_PORT_Msk) != 0))
    {
        NRF_GPIOTE->EVENTS_PORT = 0;
       //code to execute on PORT event goes here
    }
}

Be sure to remove the nrf_drv_gpiote.c file from your project or you will get multiple definitions of the IRQHandler. I suggest that you also read the Reference Manual.

[WolfgangEbersbach]

Ole, thanks. So far I got the impression that if you use a softdevice you should NOT use direct register access. Anyhow, I'll try. If I remove nrf_drv_gpiote.c, I will get 254E12 compiler errors from app_button, bsp, bsp_btn_ant and so on. I'll try.

[Ole Bauck]

You can use register access on most of the peripherals, see here for which are restricted or blocked for s130 (for other SoftDevices see own specification on PDF).