sd_clock_hfclk_request slow

[wim]

Hi

I am trying to use the internal ADC to capture an analog value every second. For this I use a timer to wake up every second, start the ADC and go back to sleep.

I used example code found on the forum. When I look at the timings, I see that this piece of code takes much longer than expected:

uint32_t p_is_running = 0;
sd_clock_hfclk_request();
while(! p_is_running) {  							//wait for the hfclk to be available
	sd_clock_hfclk_is_running((&p_is_running));
}       

I set a pin before and after the while loop, and have measured on the scope that it takes almost 2 ms to exit the loop. And I do not even power down the device yet, my main loop is just polling the event scheduler. So I think my hfclk is already running anyway.

What could be the cause of this delay?

And why is the hfclk request / release necessary? Will it keep the chip from entering in low power if the hfclk is not released? Is that not done automatically?

As an experiment, I removed the release function at the end of the ADC IRQ handler. In that case there is no delay at all. But now I am not sure of course if I do it right if I eventually will enable the power_manage() again, to go to low power in between samples or other events.

Could anyone explain the mechanism a bit more in detail?

[Stefan Birnir Sverrisson]

Hi Wim

When you are requesting hfclk, you are actually requesting to use the 16MHz external crystal. If you do not use the crystal, the internal RC will be used instead, which starts up much quicker.

In short, use the external 16MHz crystal for maximum accuracy of the ADC, use the RC to minimize current consumption.

The clock models are described here (1) (2)

[Stefan Birnir Sverrisson]

Many customers that have low power requirement and not the highest accuracy requirement use the ADC with the RC. The information in the PS is misleading, using the ADC with the crystal is not mandatory. The crystal is however mandatory for the RADIO peripheral, as stated in the PS.

The performance of the RC vs crystal is stated in tables 24 and 22 respectively.

The processor will not request the crystal, it runs on RC. It will however run on crystal if the crystal is enabled either in your application or by the sofdevice.