clock_control_on returns -EPERM on ncs 1.4.0

[basvkesteren]

Hi,

When upgrading a project from ncs 1.3.0 to 1.4.0, the clock_control_on() call behaves different; It always returns -EPERM. Did the API change?

The call is used as follows:

static int clock_init(void)
{
    int err;
    const struct device *clock;

    clock = device_get_binding(DT_INST_LABEL(0));
    if (!clock) {
        printk("Unable to find clock device binding\n");
        return -ENODEV;
    }

    err = clock_control_on(clock, CLOCK_CONTROL_NRF_SUBSYS_HF);
    if (err) {
        printk("Unable to turn on the clock: %d", err);
    }

    return err;
}

Thanks,

-Bastiaan

[basvkesteren]

Ah, right

"Unable to turn on the clock: -1"

[Håkon Alseth]

Hi,

 

Are you by any chance using the 32k RC oscillator as the LFCLK source?

I think its this line that is returned at your end: https://github.com/nrfconnect/sdk-zephyr/blob/master/drivers/clock_control/clock_control_nrf.c#L156

I was able to reproduce this error code by forcing the RC oscillator (+ calibrate on boot-up, to also request HFCLK), and immediately calling clock_control_on() in the very top of main(). Could this be what is happening on your side as well?

 

Kind regards,

Håkon

[basvkesteren]

Hi Håkon,

Did some more debugging, comparing 1.4.0 to 1.3.1; the clock-code has changed quite a bit inbetween, it seems.

When starting a clock that's already running, the 1.3.1 code continues as-is:

https://github.com/zephyrproject-rtos/zephyr/blob/v2.3.0-rc1/drivers/clock_control/nrf_power_clock.c#L263

The 1.4.0 code on the other hand returns -EPERM, as I'd noticed earlier.

And, I'm using USB, which I've just learned turns on the HF clock by itself. Oops

I've worked around this by making my clock-enable code check if the clock is running before starting it,

if(clock_control_get_status(clk_dev, CLOCK_CONTROL_NRF_SUBSYS_HF) == CLOCK_CONTROL_STATUS_OFF) {
    // Clock is off, start it
}

[basvkesteren]

Hi Håkon,

Running into another but closely related problem:

My device has USB, and we're using the radio for our own protocol, that's why I do the clock_init() stuff. I'm also using the temperature sensor to implement errata anomaly 153.

Problem is, if i run my device without USB attached, I run into this assert:

https://github.com/nrfconnect/sdk-zephyr/blob/master/drivers/sensor/nrf5/temp_nrf5.c#L65

Looks to me this is related to the HFCLK. If I disable my clock_init() code, everything as long as I keep USB connected: as soon as I disconnect it, the radio stops receiving (because the USB driver stops the HFCLK, I think?).

What's happening? It appears the USB and temperature stuff tries to be smart with the HFCLK, disabling it when it's not needed. How do I get my own code (for the radio) to tell this logic that I still need the clock?

Thanks.

-Bastiaan

[Håkon Alseth]

Hi Bastiaan,

 

Thank you for the detailed description. I have created a bug on this internally.

 

Kind regards,

Håkon