Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

[jthlim]

Hi, I recently noticed crashing in sd_clock_hfclk_is_running() on a nrf52840 using SoftDevice S140 7.3.0. This is the callstack:

??@0x00000ac4 (Unknown Source:0)

<signal handler called>@0xffffffe9 (Unknown Source:0)

sd_clock_hfclk_is_running@0x000276ae (.../nRF5_SDK_17.1.0_ddde560/components/softdevice/s140/headers/nrf_soc.h:720)

I'm using the following to enable the hfclk whenever I enable QSPI to avoid errata 244:

sd_clock_hfclk_request();

uint32_t isHfclkRunning = 0;

do {

  APP_ERROR_CHECK(sd_clock_hfclk_is_running(&isHfclkRunning));

} while (!isHfclkRunning);

I can trigger this somewhat reliably if I unplug and plug usb power while this code triggers.

Any tips on how I can avoid this issue?

Thanks,

Jeff

[Priyanka]

Hi Jeff,

Are you using a custom board or the nRF2840DK?

Regards,

Priyanka

[jthlim]

I am using a Holyiot 18010 on a custom board

The code works reliably in the absence of power being toggled to the pin

[jthlim]

The following code seems to work fine:

  sd_clock_hfclk_request();

  while (NRF_CLOCK->HFCLKSTAT != 0x10001) {

  }

Is there any downside to using this?

[Priyanka]

As long as you are using this for the nRF52840, it should be fine to use this code.

-Priyanka

[jthlim]

What is all the other stuff that sd_clock_hfclk_is_running is doing then? And what might happen differently if it's not called?

[Priyanka]

The exact operations performed by this function will vary depending on your implementation, but usually it reads certain hardware registers related to the HFCLK in order to get it's current state. It can also check whether the HFCLK source is a crystal oscillator or a synthesized clock. In case you do not call this function, it can results in various problems, say, certain peripherals that depend on the HFCLK may not function properly (like the BLE radio). It can result in timing issues too since the operations that rely on accurate timings will be affected. Also, if the HFCLK is running unnecessarily, tis will in turn increase your power consumption and reduce the efficiency of your device. Moreover, certain operations which expect HFCLK to be available and running, in case they do not get this message, can affect the stability of your system.

-Priyanka

[jthlim]

huh? That doesn't make any sense.

This is a query function -- asking is the hfclk running off the xtal -- not something that is meant to change any state. Can you elaborate why BLE radio may not function properly if the register is used to check if hfclk is running vs calling sd_clock_hfclk_is_running?

And how does sd_clock_hfclk_is_running depend on my implementation? This function is provided through SVC by the softdevice.

[Priyanka]

Hi,

It's true that the function sd_clock_hfclk_is_running does not change any state, but it simply checks the state of the HFCLK. So let's take a scenario where your HFCLK does not function properly, and this function is also not called, and then it can affect your program. Moreover, if you are not using this function, then you are using direct register checks, and if your HFCLK state is misinterpreted, this can lead to BLE radio issues. So it's always recommended to use the provided SoftDevice API functions to ensure proper operation.

Also, it does depend on your implementation, rather the way you use it in your code according to your needs, can vary depending on your implementation. 

-Priyanka

[jthlim]

Can you give an example of how my code to check HFCLK won't function properly? Before, you said the code was correct, now you're saying it may not function properly.

I would like to use the SoftDevice API, but it crashes. So that isn't an option, unless you can advise why it's crashing, and how this can be avoided.

[Priyanka]

Hi,

Apologies for the delay. De to the summer holidays we are understaffed at the moment. I have consulted your issue internally with experts, but please expect a slight delay. I will get back to you as soon as I hear form them.

Thank you for your patience.

-Priyanka

[jthlim]

Thanks for the update, looking forward to hearing more!