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:

Thanks for keep tracking this problem. Now with a new try the problem changes a little bit.

I spliced radio_test project with cli project in SDK 17.0.2 instead of 16, everything works with usb plugged in. CLI commands output a tone which I can measure in a spectrum analyzer. 

Now with USB cable unplugged, the tone didn't go away. Instead it shifts down by an offset.

For example, if cli command sets up a tone at channel 80 which is 2.48G, unplugging USB would have the tone shift down to 2.435Ghz. Similar offsets happens with other channels too.

Do you have any suggestion what could cause this shift?

Thanks again.

[Jared]

Hi,

SDK 17.0 includes a fix in the handling of the USB CLI backend when a port is closed. The changed behavior is probably related to this. I have a suspicion that your new behavior is caused by the example stopping the HFXO when you unplug the USB cable. Could you either probe the crystal or read out the NRF_CLOCK->HFCLKSTAT and see if it's stopped when you unplug the cable?

regards

Jared 

[cpeng]

Hi Jared: I will try to see if the clock stops and get back to you.

Oh and I need to clear out a confusion: in order to use radio project over USB, I had to merge the radio_test project with cli project so the CLI is through USB, not UART.

I think in the future Nordic should build a radio test project that does CLI over USB instead of UART.

Because UART needs the ARM chip on the DK board to work, and most people use radio test project on their own customized board in order to test their radio performance, and most likely the board will not have a huge ARM chip on it, so it defeats the purpose of building radio test project over UART.

[Jared]

Valid point, I'll share your thoughts onwards.. 

Looking forward to the result regarding the external crystal. 

[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