Jitter less than 20ns with STM32L476

[bardeau tracy]

Posted on March 08, 2018 at 16:28

Hi,

I've a problem with the jitter of my program on STM32L476.

First of all, I'm introduced you my project.

A signal TLL with a frequency of 1KHz to 50 KHz must be multiplied by a sinusoide or square analogique signal (10Hz to 1KHz) like a AM modulation. Then with the DAC of STM32 a results could be send in analogique format.

at the beginning I'm use a DMA for the ADC/DAC and a callback function trig by timer 6 (sampling Time 100 Khz).

In a call back function I'm get the state of the TTL and multiplied by the results of ADC (result *1 if the TTL state was SET or result *-1 if the results state is RESET), then I get the result in the DAC.

When I look the result with an osciloscope I see a 8 µs jitter and the frequency results is so bad especially near 50 Khz. period for 50Khz is 20 µs so sometime I see 35 KHz and sometime 80 KHz.

So I have modified my code like that. I made a new extern interuption on signal TTL and change the state of a variable 1 then -1. I use freeRTOS and give the high priority to the EXTI interupt. In a callback TIMER 6 i use the result of the ADC multiplied by the variable 1 or -1.

When I look the result with an osciloscope I see a 100ns jitter for the EXTI interrupt and always 8 µs jitter for the final results.

 So my question is what is the minimal jitter I could have for my project?

I don't know really freeRTOS and i do'nt understand why i can't get a prioity value less than 5. This is a probem because i want the maximum priority to the EXTI interrupts to reduced the jitter.

Can I do like that:

only one interruption EXTI on signal TTL (between 1 to 50 Khz).

in the function of EXTI :

I manually start the DAC with the value of ADC( The first conversation could be wrong but it doesn't matter)

Then I manually START ADC (one sample)

I change the state of a variable example stateTTL = StateTTL * -1 to change 1 in -1 or -1 in 1.

I multiplied the value of ADC by stateTTL.

I think when I do like that I have the jitter of only the EXTI interrupts + the DAC jitter isn't it?

I want a precison of 50 Hz at 50KHz so I must have a global jitter less than 20ns. It is Possible?

Thank you for your answear.

here i attached a schema

[Tesla DeLorean]

Posted on March 08, 2018 at 17:07

>>I must have a global jitter less than 20ns. It is Possible?

Interrupting (at 100 KHz and 50 KHz), calling through a couple of levels of handlers/callbacks, on a machine running at 80 MHz (12.5ns cycle time, perhaps >150ns latency, 50ns bus accesses). I'd be surprised.

[henry.dick]

Posted on March 08, 2018 at 19:22

'

I must have a global jitter less than 20ns.'

then you seemed to have tried all you can to defeat yourself: the use of RTOS, interrupts, multification, ..., will all overwhelm that 20ns requirement.

if you really want to have low jitter, think of a hardware based solution, like an analog / switched digital solution.

[bardeau tracy]

Posted on March 09, 2018 at 11:44

Latency is not my problem, my problem is jitter.

So if the latency is 1 or more than one Âµs it is not a problem.

if the latency is one time 1000 ns and other time 1400 ns that it a problem for me (jitter 400 ns)

I must have a constant latency for my project.

[bardeau tracy]

Posted on March 09, 2018 at 12:08

then you seemed to have tried all you can to defeat yourself: the use of RTOS, interrupts, multification, ..., will all overwhelm that 20ns requirement.

that why i will try a new solution on monday and give you my result.

my new solution is to immidatiely after a EXTI interrupt to convert a variable in the DAC.

keep the minimum interrupt ( only EXTI), I remove DMA timer 6 ... I remove RTOS wich use SYSTICK.

So my jitter could be only arrived cause of EXTI interrupt priority and Write on the DAC priority.

Like that I minimise the jitter.

for example:

results DAC T0= +30 ns

results DAC T1= +10ns

results DAC T2= -10 ns

results DAC T3= +10 ns

results DAC T4= +30 ns

results DAC T5= +50 ns

 it's not a probleme because the frequency do not really change

I think the real probleme it's the extrem and regularly jitter

results DAC T0= -20 ns

results DAC T1= +20 ns

results DAC T2= +60 ns

results DAC T3= +100 ns

results DAC T4= +140 ns

results DAC T5= +180 ns

is this case the frequency is regularly different that the frequency i want for example:

for 40 000HZ TTL I have a result of 39936 KHz.

other thing it's one time of 100 sample the result have a jitter of 100 ns it's not a problem but i must have the maximum result with the good frequency.

[Tesla DeLorean]

Posted on March 09, 2018 at 16:40

>>I must have a constant latency for my project.

The responsiveness of the system is going to be non-deterministic.

>>So my jitter could be only arrived cause of EXTI interrupt priority and Write on the DAC priority.

Really, so the cache, the flash line width, multi-cycle bus access cycles, bus contention, multi-word load/store, tail-chaining, etc won't impact things?

The phase alignment of your external clock/signals with respect to internal clock?

[Jan Waclawek]

Posted on March 09, 2018 at 18:32

my new solution is to immidatiely aftera EXTI interrupt

Forget about EXTI.

Use timer input capture to timestamp the digital ('TTL') signal's transitions. Set up DAC to be started from a timer's compare event. Sample analog input in regular 100kHz rate, and set up an interrupt triggered by the ADC conversion. In that, check if capture happened, and based on that schedule the next compare event to start DAC - a fixed number of cycles delayed from the capture, or 10us from the last compare if there was no capture - and the required value for DAC. There may be details to be resolved, e.g. to prevent DAC conversion to be scheduled closer together than the conversion duration is.

JW

[henry.dick]

Posted on March 09, 2018 at 21:02

'

my new solution is...'

how about having a realistic expectation about what your new approach can achieve? you are taking an inherently analog solution and complicate it up to be processed by a mcu. the new approach, as well as the old approach, make no sense from an engineering perspective, as far better / easier solutions exist that will deliver far better performance.

if this is an exercise, however, that's a different story.

[henry.dick]

Posted on March 09, 2018 at 21:05

just for illustrative purposes, multiplying a sine wave with a square wave is essentially turning on and off the sine wave.

So the simplest solution to your problem is to short the sine wave via a transistor controlled by the square wave.

if you want it to be MCU-centric, you can apply optionally that square wave via a MCU.

[Tesla DeLorean]

Posted on March 10, 2018 at 01:07

If you could lock the latency by locking the ADC, GPIO and DMA with a common synchronous clock you remove the jitter, then you just have to give yourself a sufficiently long window that you could forward the output patterns into the DMA buffer quicker than you can output them.

Figure a track laying engine that lifts the tracks behind itself and places them in front as it moves forward.