Timer to PPI to GPIOTE propagation delay when Softdevice enabled

[LucaF]

Hi,

I'm using TIMER1 CC0 for SAADC sample triggering through PPI and it's working well.

In order to check sampling frequency, for debug pourpose, I'm using PPI fork for toggling one GPIOPE pin.

At low frequency, about 1kHz, all seems ok.

But for higher frequency, about 2kHz or more, toggling show phase shift when softdevice is enabled.

I have not interrupt enabled on timer1, only PPI.

I'm not understand why softdevice introduces shift in the gpiote toggling signal.

I think TIMER1 to PPI to GPIOTE should be hardware routed, so software execution should not affect timeing.

What is it wrong ?

Thanks,

Luca

[Jørgen Holmefjord]

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

[LucaF]

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

Tiny-BLE-Peripheral-minimal.zip

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

Thanks,

Luca

[Jørgen Holmefjord]

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().

[LucaF]

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

[Jørgen Holmefjord]

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.