Interrupt Service Routine Jitter

[DetlefS]

Hi,

I use a STM32F767 Nucleo-144 board with a STM32F767ZIT6 processor.

With CubeIDE I configure SPI1 as I2S1 input and pump the data via DMA2/Stream0  in a short 8x16Bit circular buffer. The clock of the SPI1 is at ~ 3MHz .I set up the HAL_I2S_RxHalfCpltCallback() and  HAL_I2S_RxCpltCallback() routines. In both routines i toggle a GPIO and get a ~23.8kHz square wave.  This all works as exspected. 

But: The square wave suffers from a big jitter. First, there is a constant jitter in the range of 100ns. Second, sometimes the duty cycle (not the frequency) of the signal changes by ~330ns for some parts of a second. 330ns ist the reciprocal of my 3MHz clock.

How can I get rid of the jitter? I tried to slim down HAL_DMA_IRQHandler() to the necessary parts for my use case. That did not affect the jitter. I also changed the NVIC priorities with no effect.

How can I get rid of the jitter?

THX

Cheers

Detlef

[DetlefS]

A full cycle of my audio ie 360° is 1/23800 sec long. A full cycle of my sampling freq. is 1/3E6 long, which results in 2.856° in phase of my audio. My target accuracy is 0.5° for the audio, 58ns, 6 times as short as a single 3MHz pulse.

[LCE]

>  I also changed the NVIC priorities with no effect.

What about other active interrupts?
If the MCU is working on another ISR when the higher priority I2S interrupt occurs, could that take some additional time, going from within the current ISR to the I2S ISR ?

Maybe @TDK or @Piranha can answer this?

[waclawek.jan]

> a single missing bit

Why would you miss a bit with hardware I2S? It runs continuously, I presume, with cyclic DMA, so there's no way you miss a bit. The only requirement is, that interrupt has to be handled within half the DMA buffer.

Latency and jitter of interrupt is given by quite a couple of things in 'M7, but if it's thousands of cycles, then it's very likely some other interrupt with same or higher priority, so start perhaps looking into other parts of your code for that. Any library you are using is now part of that code of yours.

Using Cube/HAL in a timing constrained application is never a good idea.

JW

[DetlefS]

>>Why would you miss a bit with hardware I2S?

I do not miss a bit. I do not see phase jumps, I see phase jitter.

>>Using Cube/HAL in a timing constrained application is never a good idea.

I've come to the same conclusion.

THX Cheers Detlef

[waclawek.jan]

>> Why would you miss a bit with hardware I2S?

> I do not miss a bit. I do not see phase jumps, I see phase jitter.

And what is the cause of that jitter? Data are read in by I2S synchronously with I2S clock, and timing of interrupt can't change this relationship.

If you need to *generate* a square waveform synchronous with I2S clock, don't generate it in interrupt; rather, use a timer to generate it.

JW

[DetlefS]

>> And what is the cause of that jitter?

This was my question. I dunno.

Why shouldnt I generate the square wave in the  I2S? Syncronicity is forced.

I now use a syncronous timer pwm. That raised some issues as well. The calculated number of counts only works in 'up' mode, not 'down' or the centered modes. No idea why.

Thx cheers Detlef 

[waclawek.jan]

> Why shouldnt I generate the square wave in the I2S?

You mean, in the I2S interrupt? Exactly because there are many possible sources of jitter.

> The calculated number of counts only works in 'up' mode, not 'down' or the centered modes.

I don't know what do you mean by "calculated number of counts" here, and why is it a problem.

JW

[DetlefS]

>> Why shouldnt I generate the square wave in the I2S?

>You mean, in the I2S interrupt? Exactly because there are many possible sources of jitter.

Yes, but what source causes the 330ns jitter?

>> The calculated number of counts only works in 'up' mode, not 'down' or the centered modes.

>I don't know what do you mean by "calculated number of counts" here, and why is it a problem.

As I mentioned above. The nominal rating of the I2S is '96k' or, from the datasheeet 95238Hz, some percent off. So I guessed: The rate is 2016:  192Mhz/2016=95238.09524Hz. The uC clock of 192 MHz is divided by 2016 for the I2S. That is what I tried for the timer: Timer clock is also 192MHz, count to 4*2016-1, you get the 23809.52381Hz syncronous audio freq. 

That works as exspected if I count 'up', it does not work if I count 'down' or use 'center aligned' modes. In the latter cases I get phase slip.

Anyway THX Cheers Detlef

[waclawek.jan]

> Yes, but what source causes the 330ns jitter?

As I've said far above, and @LCE before me (and @TDK before him, citing particularly the SysTick interrupt, which you've dismissed without explaining, why), probably another interrupt. Or some code enabling/disabling interrupts. Or maybe your code accesses some slow peripheral on a slow bus, like FSMC or QUADSPI. It's your code, your application.

> The nominal rating of the I2S is '96k' or, from the datasheeet 95238Hz, some percent off.

What datasheet? Where does this clock comes from? How do you use I2S, master or slave? If master, how do you set its clock?

Synchronous means coming from the same clock, so you have to take the same source clock and divide that as you need.

JW

[DetlefS]

I stopped SysTick and the jitter was still present. Something is responsible for the jitter, that is very true.

The screenshot will tell you about the 95238Hz.

Cheers

Detlef