Frequency counter on NRF52805

[matangk]

Hi, I want to use an NRF52805 with a voltage to frequency detector. If I understand the datasheet, there is one timer/counter and RTC on that chip. Is it possible to set the RTC as the timing gate, and  use the T/C as an input pulse counter through the event system? I'm planning to use a single clock source (prob. 32MHz) and synthesize the LF clock required for the RTC from it.

I will be happy to know if this is a good way to go before fully adopting the hardware.

Cheers,

[Simonr]

Hi

Sorry about the late reply.

Yes sorry, it shouldn't be a HW issue since you're using the nRF52 DK for development. Glad to hear you were able to improve the rate somewhat.

Regarding the RC clock source, this is a LF clock source, but either way the external LF clock will be used by default when using the nRF52 DK.

What pins are you using for the RTC in the BLE_NUS application? I'm guessing that the fluctuations you're seeing are affected by the SoftDevice having a higher priority than the RTC peripheral, you can try increasing the priority level of your RTC if it is time critical. (interrupt level 2 or 3 is the highest allowed for peripherals).

Best regards,

Simon

[matangk]

Thanks for the reply.

As you can see from above, it seems as if it's actually the fact that the clock defaults to an RF based one, rather than the crystal clock. It makes sense since with GPIOTE and PPI, all the counting operation is done in hardware.

I really wish I could figure out how to attach a figure to a post here. Essentially, what I do is:

1) Timer1 is a timer that generates a 1s "enable window". Timer 2 is a counter.

2) I do so by attaching in PPI counter2's "start" to a compare value "1" of timer1, and attaching its "stop" to a compare value of  "62501" - one beyond 1s in my clock source setting.

3) Once a count within a frame of 1s finishes, The compare of the "enable window" end triggers an interrupt. However, do notice that the timing of this interrupt isn't critical. The counter is stopped anyway, and a winding of timer1 will not happen for a while, so interrupt priority isn't a big issue.

4) I do need to stress out that despite it not being reported, the imprecise counting of signals above ~750KHz (1.3us) requires a walkaround. Here also syntax is slightly different from documentation:

*(volatile uint32_t *)(NRF_GPIOTE_BASE + 0x600 + (4 * NRFX_GPIOTE_CHANNELS_USED)) = 1;

Also, the syntax to request the HFCLK is different for nRF connect (VS NRF51).