This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Can not use XTAL LF CLK source without softdevice on SDK15.

Hi everyone,

I want to set LF CLK source to XTAL without softdevice.
But, LFCLKSTAT value is 0x00010000(CKL RUN, CLK SRC = RC) after clock start.

So, I checked same test on PCA10056 board with "flash_fds" example.
and, I added followings after "cli_init();" in main.c
NRF_LOG_INFO("LFCLKSTAT = %08X", *(volatile uint32_t *)0x40000418);
NRF_LOG_INFO("LFCLKSRCCOPY = %08X", *(volatile uint32_t *)0x4000041C);
NRF_LOG_INFO("LFCLKSRC = %08X", *(volatile uint32_t *)0x40000518);

build: flash_fds/pca10056/blank/armgcc
CLOCK_CONFIG_LF_SRC 1
NRFX_CLOCK_CONFIG_LF_SRC 1

result:
<info> app: LFCLKSTAT = 00010000
<info> app: LFCLKSRCCOPY = 00000001
<info> app: LFCLKSRC = 00000001
LFCLKSTAT indicated that the clock source is RC.

build: flash_fds/pca10056/s140/armgcc
NRF_SDH_CLOCK_LF_SRC 1

result:
<info> app: LFCLKSTAT = 00010001
<info> app: LFCLKSRCCOPY = 00000001
<info> app: LFCLKSRC = 00000001
LFCLKSTAT indicated that the clock source is XTAL.

Can not use XTAL LF CLK source without softdevice on SDK15.
Why ?

emvironment
SDK: 15 (example flash_fds)
compiler: linux gcc-arm-none-eabi-6-2017-q2-update
board: PCA10056 

Thanks,

Parents
  • Are you actually starting the LF clock in the code? Just setting the defines won't do anything. 

  • "flash_fds example without softdevice" calls clock_init().
    and, clock_init() calls nrf_drv_clock_lfclk_request() and waits clock start by nrf_clock_lf_is_running().
    So, I think that your review point is already executed.
    "LFCLKSTAT = 0x00010000" indicated to already run LF clock also.
    But, RC source instead of XTAL.

  • Indeed! I only glanced at the example earlier, but I see that you are correct. In that case, the clock source depend on the driver configuration, and the example is configured to use the xtal by default, as CLOCK_CONFIG_LF_SRC in sdk_config.h is set to 1. I tested the unmodified example now, and it seems to work as expected. LFCLKSTAT is 0x001001 when I check with a debugger. Can you check to verify that you have not accidentally changed that in your sdk_config.h?

  • I checked it with debugger, and I got 0x00010001 value,
    but, printf debug value is 0x00010000.

    I found new phenomenon.
    I add printf debug into main loop of main.c

    and execute it,
    register value is changed on the way.

    <info> app: LFCLKSTAT     = 00010000
                                 :
                          about 50 times
                                 :
    <info> app: LFCLKSTAT     = 00010000
    <info> app: LFCLKSTAT     = 00010001

    Why?

    Bit 16 of LFCLKSTAT is RUN state,
    and I think that bit 1-0 of LFCLKSTAT is validate at bit 16 rise timing.

    does it take long time to change RC to XTAL? 

  • yes the 32.768kHz crystal has a long startup time, the documentation says 250ms is normal. 

    If you read the description in the manual 

    If the LFXO is selected as the clock source, the LFCLK will initially start running from the 32.768 kHz LFRC while the LFXO is starting up and automatically switch to using the LFXO once this oscillator is running. 

    So nrf_clock_lf_is_running() correctly returns as there *is* an LF clock running. However until the crystal has started, it's not yet the LFXO. If you actually need that clock source to be active, you need to wait for it. I assume the softdevice actually waits for the LFXO source to be active (which is why people with no crystal who forget to change the source complain the softdevice hangs). 

    So there is a slight difference between the softdevice and non-softdevice versions of the code in that one waits for the actual crystal source to run, the other just waits until there's some  LF clock source started even if it's not yet the crystal. 

  • Hi,

    As RK said, this is expected behaviour. Using the driver you can provide a event handler to the call to nrf_drv_clock_lfclk_request(), which so that you get a callback when the clock has started. This is not done in the flash_fds example, where a NULL pointer is passed instead of a function pointer to the event handler.

Reply Children
Related