I can't release( STOP ) HFCLK( XTAL ) source after I first started HFCLK source.

[Shossy]

Hello, 

I am using nRF52840 DK, and SDK version 17.1.0.

I want to dynamically control CLOCK source.

I tried to release( STOP )  HFCLK( XTAL ) source using nrf_drv_clock_hfclk_release() function after I first started HFCLK source, but it seems not to be working properly. ( HFCLK NOT STOPPED after using this function. )

Is it possible to dynamically STOP HFCLK( XTAL ) source while the board is on and connected to another board by BLE ?

Thanks.

Shossy

[Einar Thorsrud]

Hi,

When using a SoftDevice, the application can request or release the high frequency crystal oscillator (HFXO)t. However, it cannot explicitly stop it, as the SoftDevice needs to and will keep it active whenever it uses the radio, as an accurate clock is a requirement for radio usage (it is also used in some other cases, for instance regularly calibrating the LFRC if that is used). In other words, the application can ensure that the clock is running when it needs it to (by requesting it before and releasing it afterwards), but cannot be sure that it never runs.

Why do you you want to explicitly stop using the HFXO? The way the system works, the HFINT which is an inaccurate low power clock is used by default when a high frequency clock is needed, and this is started automatically by the HW when the CPU or any periperals that need a high frequency clock is running. Then, SW (your or the SoftDevice) can enable the HFXO when an accurate clock is needed, and release it whenever it is not needed. When there are no "users" needing an accurate high frequency clock, the SoftDevice will disable it (meaning that still the low accuracy HFINT may be used).

Is it possible to dynamically STOP HFCLK( XTAL ) source while the board is on and connected to another board by BLE ?

If I understand the question correctly, then no. Communication over BLE means over the radio, and it is physically impossible to use the radio successfully without using the HFXO (the HFINT is way to inaccurate).

[Shossy]

Thank you for answering my question.

The reason why I want to explicitly stop using the HFXO is  I want to save current value and power consumption when the HFXO is considered to be unnecessary. 

I am currently studying the way of synchronizing several nRF52840 boards achieving synchronization accuracy and low power consumption. 

Thanks.

[Einar Thorsrud]

Hi,

Shossy said:

The reason why I want to explicitly stop using the HFXO is  I want to save current value and power consumption when the HFXO is considered to be unnecessary. 

That makes sense. And that is how the system is already designed. If you are not able to stop the HFXO, then that is because all that use it have not released it. It could be that you have called nrf_drv_clock_hfclk_request() more times than you  have called nrf_drv_clock_hfclk_release(). Alternatively, that the SoftDevice needs it because of using the radio in that instant.

[Shossy]

Thank you for your reply.

I have changed the release code " nrf_drv_clock_hfclk_release(); " into  " 

while(nrf_drv_clock_hfclk_is_running()){

nrf_drv_clock_hfclk_release();

} "  after reading your reply message,

By doing this, I managed to completely release the HFXO source , and I can check that by using the function " nrf_drv_clock_hfclk_is_running() ". 

Does this doing cause problem about BLE connection ?

I plan to use the HFXO again after releasing the HFXO by using "

while(!(nrf_drv_clock_hfclk_is_running())){
nrf_drv_clock_hfclk_request(NULL);
}

Thanks.

[Einar Thorsrud]

Hi,

Shossy said:

Does this doing cause problem about BLE connection ?

No, it will not cause problems with the BLE connection, as the SoftDevice will still not stop the HFXO while it needs it.

However, this is not an appropriate approach. As this seems to fix the issue, it means that you nrf_drv_clock_hfclk_request() was called more times that nrf_drv_clock_hfclk_release() before you started calling that in a loop. The point here is that for every "user" that needs the HF clock that request it, and a counter counts up. when no longer needing it, release it. And then the counter counts down. When the counter reaches 0, that means that all requests has been released, so that there i no more need for the HFXO. With your hack you break this mechanism, so either you now have a bug where the HFXO is requested several times or when not needed that you "fixed" in a hackish way, or you now release the HFXO before you are actually done with it (either because you need it somewhere else in your code, or some SDK library you are using requested it because it is needed).

In short, you should never call nrf_drv_clock_hfclk_request() or nrf_drv_clock_hfclk_release() in a loop like this, as it completely ruins the way this is intended to work.

[Shossy]

Thank you for your reply,

I want to check the following. 

In summary, I must not completely release(STOP) HFCLK source by 

while(nrf_drv_clock_hfclk_is_running()){

   nrf_drv_clock_hfclk_release();

}

after explicitly starting HFCLK source in advance ??

( If I use only once the function nrf_drv_clock_hfclk_release() , I can not completely release( STOP ) HFCLK source. )

Is this understanding correct ??

This is fatal thing for my study.

Thanks.

[Einar Thorsrud]

Yes and no, that is not entirely correct. If you call nrf_drv_clock_hfclk_request() 1 time, and then call nrf_drv_clock_hfclk_release() the HFXO will be stopped (unless the SoftDevice use it, and in that case, it will be stopped when the SoftDevice is done using it).

But it is right that you should never call any of the release or request functions in a loop. It would break the concept of counting up requests and counting down releases, which is there to ensure that the HFXO is always enabled as long as it is need (anywhere in the code, potentially in some library or driver implementation do now know about or another part of the code a colleague of you wrote that you don't know about), and immediately disabled when no longer needed.