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,

 

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
}

[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

[Krzysztof Chruscinski]

Hi,

handling of HF clock control changed in 1.4. HF clock has multiple clients (radio, usb, temp, etc.) and previously this was managed inside the driver. Recently, zephyr added a generic module for handling cases like that - on-off manager https://docs.zephyrproject.org/latest/reference/resource_management/index.html#on-off-manager

it allows to simplify the driver because complex management of multiple users is extracted from the driver. Driver was adapted as a result clock_control.h api is just turning on and off the clock and provides no clients management. Driver shall be accessed using onoff API. There is an api for getting on-off manager associated with the given clock. Additionally, driver detects if onoff manager was already used on given clock and returns -EPERM if clock control api is accessed directly.

On-off manager can be fetched like here: https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/sensor/nrf5/temp_nrf5.c#L120

And then on-off api is used instead of clock_control.h.

github.com/.../temp_nrf5.c

[basvkesteren]

Thanks, this works as expected!