Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

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
Parents Reply
  • 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.

Children
  • 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

Related