The PWM pluse width flutter on NRF52

RE: The PWM pluse width flutter on NRF52

Einar Thorsrud — Fri, 03 May 2019 13:12:03 GMT

Hi,

The pointer to the event handler is only relevant if you want to know when the crystal oscillator has been started. For instance, if you want to start the PWM output as soon as possible, but not before the clock is stable. If you don't need this callback/event, then you just pass a NULL pointer. It does not affect the stability of the system in any other way.

RE: The PWM pluse width flutter on NRF52

tin39 — Fri, 03 May 2019 12:33:27 GMT

And I have a doubt that what is the input formal parameter of the function nrf_drv_clock_hfclk_request().

I just use NULL, and it works. I am worry about that whether it will make the system unstable if I use NULL as the input parameter?

RE: The PWM pluse width flutter on NRF52

tin39 — Fri, 03 May 2019 12:20:38 GMT

It is awesome! It works I put the two functions after I initialize the SoftDevice. The pwm is never flutter. Many thanks!

And I did another try one hour age, and it make the pwm no flutter too.

I put the code below before I initialize the SoftDevice.

NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
NRF_CLOCK->TASKS_HFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

I guess that when the softdevice is initializing. The softdevice will check the HFCLK status. If the HFCLK is started, the SoftDevice will no longer disable the external crystal oscillator; If the HFCLK is not start, the SoftDevice will manage the crystal oscillator and disable the external crystal oscillator when it no longer needs it.

Do my guess correct?

And which method is better and more reliable?

RE: The PWM pluse width flutter on NRF52

Einar Thorsrud — Fri, 03 May 2019 10:38:27 GMT

Hi,

I was not clear in my previous reply. You must move these function calls after initializing the SoftDevice for it to be persistent. If you do, the driver will use the SoftDevice API to request the clock, and this tells the SoftDevice to not disable the crystal oscillator when it no longer needs it. Can you try that?

RE: The PWM pluse width flutter on NRF52

tin39 — Fri, 03 May 2019 09:48:23 GMT

Thank you for your reply! I have try the two functions you mentioned, I put them in the beginning of the application. But they are not working, the problem is still. I have monitor the crystal waveform. The external 32MHz crystal is not always working. I think the softdevice is still switching the clock between the external 32MHz crystal and the interanl 64MHz oscillator.

RE: The PWM pluse width flutter on NRF52

Einar Thorsrud — Thu, 02 May 2019 11:41:29 GMT

Hi,

Both the PWM driver and PWM library should be as accurate as the HF clock. The reason is that the PWM peripheral (used by the driver) runs of the HF clock, and the PWM library use a TIMER which also use the HF clock, and controls the output via PPI, which is deterministic.

Therefor I am tempted to think that the problem here could be related to your clock source. Can you try to request the HF clock with nrf_drv_clock_init() and nrf_drv_clock_hfclk_request() in the beginning of your application, and see if that helps? In that case the 32 MHz oscillator will always be used, instead of it being turned on only when the radio is on, and off otherwise. When this is enabled, the (average) accuracy of the PWM signal will be the same as the accuracy of your 32 MHz crystal (which is the reference for the 64 MHz HF clock).