Timing-Jitter on gpio output when LCD is active.

[Beck.Karl-Michael]

Posted on March 08, 2017 at 16:06

Hi guys,

we have a problem here. We run a Stm32F469BITx at 180 Mhz. There is a lcd display and a realtime process included. The realtime process creates GPIO-Pin-Changes in Mikrosecond intervalls. The problem is that we have a timing jitter of about 6us. The realtime process has highest prio, even we disable interrupts now while it is pending. Although the jitter occurs. When we disable the display the jitter goes < 1 us.

So definitiely no interrupt during the realtime process. Where could the jitter come from?

Thanks for your thoughts.

[Beck.Karl-Michael]

Posted on March 08, 2017 at 16:22

To clarify this: The realtime interrupt sets portpin to 1 uses tim13 to do a while loop doing a blocking wait.

Then sets the portpin to 0.

So there is no exit of the interrupt routine (timer interrupt not used).

Although the timing varies about 6us when lcd is active.

In the rt-interrupt routine we use __disable_irq to be sure nothing interrupts the realtime process.

[Tesla DeLorean]

Posted on March 08, 2017 at 16:38

Is TIM13 free running? What is the frequency of the TIM?

You are saying the pulse width varies by 6us?

Is the Frame buffer in internal SRAM or external SDRAM? Or on the display?

[Beck.Karl-Michael]

Posted on March 08, 2017 at 20:30Is TIM13 free running? I suppose so, i don't even know how to make a timer depending on another.It just counts down...

What is the frequency of the TIM?

...one step per mikrosecond. = 1000000 hz

You are saying the pulse width varies by 6us?

yes.

Is the Frame buffer in internal SRAM or external SDRAM? Or on the display?

External sdram. The application has allocated its data on this memory too.The internal sram i use for the stack.

[waclawek.jan]

Posted on March 08, 2017 at 23:06

The jitter is in timing of successive rising edges, or in timing inside the pulse?

The application has allocated its data on this memory [external SDRAM shared with LCD framebuffer] too.

Bad idea.

In the 32-bitters, realtime stuff should be handled purely by hardware as much as possible. A simple stream of pulses can be generated by timers, more complex pulses pattern by a combination of timers and DMA.

Generally, the more the application goes towards 'general-purpose computing' and 'high computing power', the poorer the realtime performance; for multiple reasons.

JW

[Beck.Karl-Michael]

Posted on March 09, 2017 at 10:41

The jitter is in timing of successive rising edges, or in timing inside the pulse?

The rising and falling edge varies in time. As if the timer would not give accurate results. 

The application has allocated its data on this memory [external SDRAM shared with LCD framebuffer] too.

Bad idea.

Why is that? Does the communication between Displaycontroller and sdram affect the communication in the application code accessing the sdram? I store some data for the state machine in the sdram. Could it work better if i store the data in the internal SRAM?

[Beck.Karl-Michael · Accepted solution]

Posted on March 13, 2017 at 14:07

Ok. The problem cause was:

- The transfer of the framebuffer from the SDRAM (used as Video Ram) which happens during the display refreshing (for example 60x per sec) was disturbing the access of the data used in the interrupt which was also allocated in sdram. That was enought to get a jitter of ~6 us.

The solution:

[1]: Use an extra memory for video ram. For example in the display. (Not possible in my case)

[2]: Allocate the data used in the interrupt in the iram rather than in the sdram.

[2] did it. The jitter now is not more than 200 nanoseconds. That's accurate enough for our use case.

Thanks for the tip.