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,

[Daniel Chisholm]

If you are getting wild variations, make sure you are using crystal (HFCLK I think?) not RC as your high speed clock source.

[matangk]

Isn't the BT uart example using the DK52's HS crystal by default? What is the procedure to switch?

Tnx

[matangk]

Excellent suggestion! I didn't understand that by default the crystal source might be unused..

OK, I *think* I sorted this out. I was using a previous example:

	NRF_CLOCK->TASKS_HFCLKSTART = 1; //Start high frequency clock
	while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
	{
		//Wait for HFCLK to start
	}
	NRF_CLOCK->EVENTS_HFCLKSTARTED = 0; //Clear event

and assumed that this will force start the crystal clock. For some reason it doesn't. Online I saw that is NRF51 this was recommended to do with sd_clock_hfclk_request();

***annoyingly*** the nRF connect SDK API is different and ***undocumented***. Neither are examples nor explanations in the API that does exist what the sd request has turned into.

What did it for me is putting in my main() function (after BT and uart service have started) the following:

mpsl_clock_hfclk_request(&hfclk_started_callback);
	uint32_t is_running = 0;
	while (is_running==0){
	mpsl_clock_hfclk_is_running(&is_running);
	}

This requires a definition of cb function (I put it before main())

void hfclk_started_callback(){

}

I then used an Arduino configured as a clock source (WITH A RESISTIVE DIVIDER! IT'S WORKING AT 5V, DONT BURN YOUR INPUT PIN!) as follows (this is the Arduino code):

const int freqOutputPin = 9;   // OC1A output pin for ATmega32u4 (Arduino Micro)
const int ocr1aval  = 7; 

void setup()
{
    pinMode(freqOutputPin, OUTPUT);
    
    TCCR1A = ( (1 << COM1A0));
   
    TCCR1B = ((1 << WGM12) | (1 << CS10));

    TIMSK1 = 0;
    
    OCR1A = ocr1aval;    
}

void loop()
{
   
}

Results over 400 samples with 1MHz clock input

Before requesting HF clock: Average Frequency 997968.1Hz, STDEV=277.6Hz (ppm)

After requesting HF clock: Average Frequency 999351.7Hz, STDEV=0.45Hz (ppm)

FYI

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