This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

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

  • It doesn't matter if ap_twi uses it - not that it could, if it did you'd have multiple GPIOTE_IRQHander() functions and your code wouldn't link. All that unavailable error code means is that the interrupt is unavailable because the softdevice uses it, and since we know it doesn't, it must be the other one.

    Since you say you don't set the priority - that's your problem - default 0, softdevice doesn't like that. Set it to APP_PRIORITY_HI or LO or whatever the constants are. There's an sd_* function for that too, or just call the NVIC_* one

    I wonder why Keil eats error codes, don't use it myself. Often feel like using Keil must be like ploughing a field with a horse, possible, but really hard work.

  • Jepp, RK , that's it. I set the interrupt priority to "1" ( no, no 37-letter-define used ) and it works. Thanks a lot ! So, maybe the nrf_drv_gpiote_in_init I originally wanted to use also defaults to interrupt priority 0 and thus failed ? Again, thanks to all for helping me out. Over time, the number and stupid-ness of my questions will degrade :-)

  • I am glad you found the issue, I did not know the default interrupt priority was 0 and rather thought it was 3 (APP_PRIORITY_LOW), now I learned something :).

    Regarding the nrf_drv_gpiote failing, this is fixed with changing

    #define GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS 4
    

    In nrf_drv_config.h to a higher number (the bsp module takes 4 so none was left). I am sorry this took so long, but the guy who could help me was sick. Since it is not well documented that this macro have to be changed I will make an internal case on this.

  • Ole, thanks for the reply. In the meantime I removed the entire BSP stuff, so now it should also work with the nrf_drv_gpiote, but for now I leave it as it is - with direct register access. This is a nice example how too may layers of #defines and macros can lead to code that no one can understand...

Related