How to prevent Radio test from stopping with cli disconnected?

[cpeng]

Hi Devzone:

We put the radio test project on our custom battery powered board and encountered a problem.

When we disconnect the usb cable, the tone emitted by radio test project disappeared.

We want to disconnect the cable as the cable could act as an antenna.

Why the radio test needs usb cable connected to keep running? Where can I modify the code so that disconnecting cable would not stop the test?

Thanks.

[Jared]

Hi,

How is the board supplied and what transport layer are you using for CLI module?

regards

Jared

[cpeng]

Hi Jared:

Thanks for reaching out to help.

The board is a customized board that has a usb port on it.

The cli module  transport layer is usb cdc acm through that port.

I merged the radio test with cli example, because the original radio test project uses UART instead of USB cdc.

[cpeng]

Hi Jared:

I finally got a chance to probe the crystal, as you have predicted, yes the external crystal stopped when USB cable is unplugged, indicating Nordic switched to internal oscillator.

Now the question is how to modify the code to prevent Nordic from doing this switching.

If you know it by any chance that would save me some effort digging into the documents.

Thanks again for your advice.

[Jared]

Hi,

The radio_test example activates the HFCLK by writing directly to the register. Are you requesting the clock again or using the clock driver in any other place in your code? What changes did you do in the application? My guess is that the register is written to an additional time somewhere in your code. 

[cpeng]

Problem solved!

I put 

NRF_CLOCK->TASKS_HFCLKSTART    = 1;

in the main() while loop to constantly re-write the register, and now the crystal stays on when USB cable is unplugged.

My guess is somewhere in the USBD api function calls Nordic turns HFCLK off when usb power is unplugged.

however I searched in the code i couldn't find any relevant place where Nordic does that.

[Jared]

Hi,

Sorry for the late reply. Good that it worked. In regards to where the HFCLK is written to in the USBD API, most of our examples do this during the initialization routine. For example the USBD example:

Are you doing something similar?

regards

Jared 

[cpeng]

Hi Jared:

I added this code to cli usb example project, the added lines are in the main() function.

[Jared]

My last point was referring to your previous question about where the USBD driver might be turning off the clock. We've seen earlier that a call to request the hfclk clock with the nrf_drv_clock driver will effectively turn off the clock if the clock was already running and was initially turned on by writing directly to the register. I was therefore curious if you during the initialization process was requesting the hfclk clock for example in usbd_init()

regards

Jared 

[cpeng]

Hi Jared:

In the main(), usbd_init() is indeed called, but that function is the original code in the cli example project written by Nordic. I did not modify it. Can you tell if it's turning off the HFCLK? Below is the code:

static void usbd_init(void)
{
#if CLI_OVER_USB_CDC_ACM
    ret_code_t ret;
    static const app_usbd_config_t usbd_config = {
        .ev_handler = app_usbd_event_execute,
        .ev_state_proc = usbd_user_ev_handler
    };
    ret = app_usbd_init(&usbd_config);
    APP_ERROR_CHECK(ret);

    app_usbd_class_inst_t const * class_cdc_acm =
            app_usbd_cdc_acm_class_inst_get(&nrf_cli_cdc_acm);
    ret = app_usbd_class_append(class_cdc_acm);
    APP_ERROR_CHECK(ret);

    if (USBD_POWER_DETECTION)
    {
        ret = app_usbd_power_events_enable();
        APP_ERROR_CHECK(ret);
    }
    else
    {
        NRF_LOG_INFO("No USB power detection enabled\nStarting USB now");

        app_usbd_enable();
        app_usbd_start();
    }

    /* Give some time for the host to enumerate and connect to the USB CDC port */
    nrf_delay_ms(1000);
#endif
}

With a rough scan I didn't find any "nrf_drv_clock " related code in here that could cause HFCLK be turned off.

[Jared]

Hi,

The HF clock is requested in the app_usbd.c driver more specifically in sustate_set(). Either way I guess the original issue is solved?

regards

Jared 

[lorenzoFIL]

I know this thread is a bit old, but I was encountering the same issue and thought it might be helpful for others. 

It looks like when USB is disconnected and app_usbd_stop() is called, if you go down the rabbit hole, you'll end up in app_usbd.c and in the APP_USBD_EVT_STOP_REQ event, the code will try to release the hfclk in line 1106 of SDK 17.0.2. Hopefully this is helpful for others in the future.