Timer to PPI to GPIOTE propagation delay when Softdevice enabled

RE: Timer to PPI to GPIOTE propagation delay when Softdevice enabled

Jørgen Holmefjord — Wed, 20 Jul 2022 21:32:32 GMT

The drawback of running the HFXO at all times is that the current consumption is not going down when the CPU is sleeping. Since you are running a TIMER anyways, you will anyway not get to very low current, but you can check the different current consumption numbers in TIMER running.

RE: Timer to PPI to GPIOTE propagation delay when Softdevice enabled

LucaF — Fri, 08 Jul 2022 09:35:58 GMT

In fact, I was not clear, sorry.
Using mpsl_clock_hfclk_request() the phase shift disappeared, so you right.
Are there drawbacks using HFXO ?
Thanks very much,
Luca

RE: Timer to PPI to GPIOTE propagation delay when Softdevice enabled

Jørgen Holmefjord — Thu, 07 Jul 2022 12:57:05 GMT

Sorry, I assumed you were using nRF5 SDK, as you said Softdevice and did not specify the SDK version/variant. It looks like you are using nRF Connect SDK and the Softdevice Controller. Then the corresponding API to sd_clock_hfclk_request() would be mpsl_clock_hfclk_request().

RE: Timer to PPI to GPIOTE propagation delay when Softdevice enabled

LucaF — Thu, 07 Jul 2022 12:40:24 GMT

Hi Jørgen,

Here some snapshot on the oscilloscope with persistence enabled.

Green track is the start sampling signal on gpio P0.29 (oscilloscope trigger on this signal)

Yellow track is the sampling signal on gpio P0.30 (toggling at each timer CC0 event)

You can see that whereas left side of the track is sharp, the rigth one is blurry.

Sampling at 4kHz during advertisement - track on the rigth is blurry

Sampling at 4kHz after connection, no data sending - still bllurry but less blur

Sampling at 8kHz with no BLE, almost no blur

Sampling at 8kHz after connection - track on the rigth is blurry

Here a minimal code I prepared for test. I used nRFConnect SDK and toolchain v. 1.9.1

devzone.nordicsemi.com/.../Tiny_2D00_BLE_2D00_Peripheral_2D00_minimal.zip

Sorry, I were not able to find sd_clock_hfclk_request() function, where is it defined ?

Thanks,

Luca

RE: Timer to PPI to GPIOTE propagation delay when Softdevice enabled

Jørgen Holmefjord — Tue, 05 Jul 2022 14:03:02 GMT

Hi,

Can you post your code to setup the TIMER/PPI/GPIOTE, and logic traces showing the phase shift you are observing?

The PPI signals should be implemented in HW, and should not be affected by the SoftDevice as far as I know, however, the PPI signals are synced to the 16MHz clock, so it will be delayed (up to) one clock cycle:

"On each PPI channel, the signals are synchronized to the 16 MHz clock to avoid any internal violation of setup and hold timings. As a consequence, events that are synchronous to the 16 MHz clock will be delayed by one clock period, while other asynchronous events will be delayed by up to one 16 MHz clock period."

Have you tried starting the HFXO in your application and keep this running all the tie, to see if it is the Softdevice's starting of the HFCLK that is affecting your timer? You can use the API sd_clock_hfclk_request() to achieve this.

Best regards,
Jørgen