High frequency PWM shifts phase when radio is active

[grow mane]

When setting up a 1Mhz square wave using NRF_PWM on the NRF52 or GPIOTE on the NRF51 while BLE is advertising, the PWM stops when the radio is active. The problem doesn't happen when the frequency is below 6khz. No PWM interrupt is enabled. Is this an unavoidable limitation with high PWM frequencies?

[TeleToby]

I'm also experiencing this on my nrf52. I can see the advertising events causing the artifacts in the pwm output.

1. Advertising interval = 125x 0.625 ms = 78 ms
2. Advertising interval = 250 x 0.625 ms = 156 ms

This might be caused by the BLE-event requesting a clock change from RC to XTAL.

sd_clock_hfclk_request() did the trick in my case.

[Luis]

Did you solve it then? Using that function? Where did you place it?

[TeleToby]

I call the function before I do ble_advertising_start(). I just tested this to see if the artifact disappared in my pwm output (I'm playing a 38khz sine), and it did.

This was just for test purposes, so I never release the HFCLK after that.

Whether this a solution or just a workaround I'll let the Nordic folks answer :)

 uint32_t p_is_running = 0;
	sd_clock_hfclk_request();
	while(! p_is_running) {  							//wait for the hfclk to be available
		sd_clock_hfclk_is_running((&p_is_running));
	}

    err_code = ble_advertising_start(BLE_ADV_MODE_FAST);

[Ole Bauck]

I am not able to reproduce it here yet, tried on several boards, but no glitch in the PWM.

Starting the crstyal with sd_clock_hfclk_request() will be the current workaround, there are no drawbacks with doing this other than an increase in current consumption, see here. Running from the crystal will also get higher accuracy (20 ppm crystal on DK vs 1.5% typical for internal oscillator). I will update when I have been able to reproduce this and know more.

Could you attach a higher resolution picture showing the artifacts more closely so I can see the timing and such (upload the file to the answer)? You are using nRF52 DK? Which version or which version of the chip?

[grow mane]

sd_clock_hfclk_request didn't do anything for me. Looks like the clock can be configured once during startup, using SOFTDEVICE_HANDLER_INIT to use the hfclk to synthesize the 32khz clock, but any attempt to change the clock later does nothing or crashes it. This eliminates the clock instability, but uses 1mA which is too high without a way to disable it at runtime.

Visualizing the artifact requires an oscilloscope sampling below 100 ksamples/sec & an 800khz square wave synthesized by PWM. There hasn't been a directly observable change in frequency, only a DC alias. The workaround has been only doing time sensitive operations when the radio is inactive, but this makes it really slow.