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

[Håkon Alseth]

Hi,

 

Could you try adding this define?

#define DT_DRV_COMPAT nordic_nrf_clock

 

The whole snippet should then be something like this:

#include <drivers/clock_control.h>
#include <drivers/clock_control/nrf_clock_control.h>

#define DT_DRV_COMPAT nordic_nrf_clock

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;
}

 

Kind regards,

Håkon

[basvkesteren]

Hi,

Thanks; I indeed have that line, and the includes, in the source-file with clock_control_on() call. Omitted them in the snippet...

The problem remains, though.

[Håkon Alseth]

Hi,

 

What is the print out? I'm not seeing this at my end, unfortunately.

 

Kind regards,

Håkon

[basvkesteren]

Hi Håkon,

Not sure what you mean by print out here?

[Håkon Alseth]

Hi,

 

The printk output, from the terminal/RTT session.

 

Cheers,

Håkon

[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
}