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.

[Jared]

And is the board still supplied after you plug the cable out? What is supplying the board? 

cpeng said:

I turned off all asserts, the tone generated by radio test still vanishes after usb cable is pulled off.

How did you do this? I don't see how this would solve the issue. Have you routed the SWD pins out so you could connect the board to a debugger? Could you try to see what the application is doing when you plug out the usb cable? 

[cpeng]

Hi Jared, sorry I wasn't very specif in describing what I did:

by turning off all asserts, I just commented out ASSERT lines in nrf_cli_uart.c, nrf_cli.c, nrf_queue.c

I guess it's probably not beneficial to do.

The board is powered by battery, so after USB cable disconnected the code still runs.

I did have the board swd pins still connected after I disconnect the usb cable, and fired up the debugger.

Do you have any recommendation of what to check? The debugger shows the code still runs, bouncing between some nrf_cli files.

[Jared]

Hi,

The example uses CLI which again is dependent on the USB peripheral if you chose USB as the transport layer. CLI is used for communicating with the user on how to setup the test. You would have to modify the entire example so that it isn't dependent on the USB as transport layer. I haven't tested this but you could try to use the UART  as transport layer instead.

regards

Jared 

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