Jitter on timer created pulse (proabably by higher priority ISRs)

[shaif]

We are currently experiencing a problem during development of Medical device.

We are currently using nRF52832 on Thingy52 prior to bring up on the product board having nRF52840.

The application must maintain BLE communication point to point , while required to produce accurate pulse trains of length 50 to 250 us. with +/- 5 us tolerance

Each pulse is composed of 8Mhz clocks.

We are using timers and GPIO with ISRs.

The problem : we are experiencing a Jitter of 10 to 20us over the pulse train length.

 

We want to work with GPIO_TE to prevent the jitter

 I believe that the Soft Device ISRs have the maximal priority , therefore it will get the priority over timer interrupts and GPIO_TE interrupts.

We are not allowed to disable Soft Device ISRs.

 

Can you suggest an operative way of preventing this jitter/changing the mode of work? GPIO_TE ?

[haakonsh]

The application must maintain BLE communication point to point , while required to produce accurate pulse trains of length 50 to 250 us. with +/- 5 us tolerance

Is this a fixed-period signal like PWM, or a kind of arbitrary bitstream? 

 

We are using timers and GPIO with ISRs.

 Any timing controlled via CPU is going to experience jitter due to the SoftDevice's higher execution priority, unless you can run it in a Timeslot, where the SoftDevice guarantees not to preempt application code in a given slot of time.

You might be able to use the TIMER with GPIOTE, but we need more detailed information about the nature of your pulse trains. 

Another alternative might be the PWM — Pulse width modulation peripheral. You can run fairly long sequences, read from RAM via EasyDMA, without any intervention from the CPU. You only need the CPU to update the sequence buffers between each run of a sequence. 

[shaif]

The pulse may be 50us +/-5us every 33ms +/- 1ms

Can we use the PWM with EasyDMA option to achieve this?

We assumer we will need a 4KB buffer for this , is this feasible?

[haakonsh]

shaif said:

The pulse may be 50us +/-5us every 33ms +/- 1ms

Do you mean to say that it uses a fixed period of 33ms, if so then the PWM peripheral is an excellent choice, as it has a time resolution of 62.5ns.
I'm fairly certain that the PWM peripheral is the best choice, even if the period must vary with +/-1 ms for each duty-cycle sample. 

shaif said:

We assumer we will need a 4KB buffer for this , is this feasible?

One sequence can be as long as 2^14 samples of 16bit =  2^14 * 2 = 32,768 bytes. A 4096 byte buffer can hold 2048 samples/duty-cycle values. You will need to have 4kB of RAM available ofc. 

You can also loop a sequence 'n' times, or chain different sequences together. 

By using the PWM peripheral you'll get a jitter defined by the clock accuracy of the PWM peripheral, the peripheral clock system, PCLK16M, is derived from the HFCLK controller. by default, the HFCLK runs on an internal 64MHz RC oscillator, shared with the CPU and the rest of the system. If you need better clock accuracy then you can use the 32MHz external crystal oscillator, HFXO, as the source for the HFCLK.
The HFXO usually has a frequency tolerance of <60ppm, and exceptionally low jitter.