Major problem with STMH743 version "V"

[PMath.4]

I've got a complex program running on the STM32H743 using LTDC to drive a VGA monitor, FMC for a SDRAM, and USB host to a keyboard. This works perfectly on the "Y" version of the chip.

On the "V" chip it works but the LTDC output is less stable and the monitor occasionally drops sync. Both chips are running at 400MHz on identical PCBs. The LTDC framebuffer is in the 512Mb internal memory section. The effect is replicated with different chips. There is nothing in AN5312 that could explain the issue. The code is using the latest HAL libraries.

Looking on the scope you can see jitter on the sync pulses. Even more bizarrely the jitter is data dependent. the higher the VGA intensity level displayed (bigger numbers in the framebuffer) the more likely jitter is to occur. The size of the effect is highly dependent on the PLL setting of both the processor clock and the LTDC clock. It seems like on the "V" part the PLLs are much less stable than on the "Y" and can be knocked out of sync by various types of activity within the chip. For example setting DIVM1, DIVN1 and DIVP1 to 1, 100, 2 is more stable than 2, 200, 2 (VCI range set properly in both cases).

I've spent many hours tuning PLL setting to reduce the effect as much as possible but this is now a major issue for rollout of a project as I can't rely on sourcing "Y" parts going forward.

Is there any known issue with the "V" version that could explain this and can someone from ST please suggest any way forward. Are there changes in the "X" version of the chip that my improve this - Has anyone seen a "X"?

[waclawek.jan]

Sounds like inadequate power source or, maybe even more probably, inadequate grounding arrangement.

Review these, especially around the analog power source (which supplies the PLL). Review decoupling arrangement. Avoid common path with tracks leading to the LCD and (probably more importantly) to the external memory (again, including ground). Improve/rearrange ground to LCD and SDRAM. Try to identify any other possible high-consumption source. Try to lower the outputs drive (in GPIO_OSPEEDR).

Try to switch of SDRAM entirely and run LCD out of the internal SRAM (prehaps using some 8-bit mode). I'm talking about a simple testing program, trying to display a pattern which causes the most problems (high-contrast vertical stripes perhaps?) Does it make a significant difference?

What is the primary clock source? You surely don't use the fractional PLL, do you? Also, the 'F4 material recommended to run the PLL's VCO as high as possible for decreased jitter, this might be similar here based on jitter parameters given in DS - but you've probably tried this already, did you?

I know you don't want to hear this, but I wouldn't expect this to be solved by software or by using a particular revision of the chip. Isn't the "Y" part causing less problems used on a different version of PCB, btw.?

JW

[PMath.4]

This is definitely a "V" issue. I have swapped a "Y" chip onto the PCB that was running the "V" and the problem goes away. Definitely no fractional PLLs. The framebuffer is already in internal SRAM using an 8-bit mode. I have already changed the output speed to the lowest setting that works. The analog supply is fed via a 10ohm resistor with 0.1uF, 1uF and 10uF capacitors across VDDA and GND. This gives a totally clean and stable voltage.

[Bassett.David]

Which version of HAL are you using?

[PMath.4]

1.7

[berendi]

I had somewhat similar problems with STM32H743ZI/STM32H743II. Some clocks were off by 10% with CubeMX generated clock setup.

I have replaced SystemClock_Config(), implementing every step of the clock setup with direct RCC register accesses. Now it's working without any issues, driving a 800x480 TFT display, framebuffer in external SDRAM.

Look here for a starting point.

[waclawek.jan]

@berendi​ 

> Some clocks were off by 10% with CubeMX generated clock setup.

Isn't that the known Cube bug, setting unnecessarily the HSI trim to a value which is incorrect for some of the revisions? I don't use the 'H7 so don't store pointers to these.

([EDIT] e.g. https://community.st.com/s/question/0D50X0000B41tlASQQ/stm32h743-hsi-frequency-waaaayyy-off [/EDIT])

If it's so, it's not *jitter* but *incorrect frequency* - I believe these are distinguishable.

@Community member​ you did not answer this question:

> What is the primary clock source?

Output the system clock (or whichever clock is source to LTDC) and observe its jitter.

If the framebuffer is in internal SRAM, why did you mention the external SDRAM? If there's anything going on with it, cut it down - did it make any difference?

Cut down *all* code which is not relevant to LTDC, down to the barest possible bone - still jitter?

Disconnect the target LCD. Still jitter?

Try the same on a "known good" hardware such as a Nucleo board - still jitter?

JW

[berendi]

It was rather jumping between the right value (100MHz) and 90 MHz. Did not investigate it further, the problem was gone when I did it without HAL.

[PMath.4]

System Clock source is an 8MHz crystal

The jitter disappears when the system is simplified but that isn't a useful test. The issue is that this only occurs on the "V" part and not on the "Y".

The absolute proof is that I have replaced on the same physical PCB a jittery "V" with a "Y" - no other changes and the jitter doesn't occur.

Something about the "V" is different that makes its PLL clocks more susceptible to apparently losing lock. This doesn't happen if the application is simple but does when there is lots going on. Multiple interrupts, FMC refresh and access, copies to and from the framebuffer etc. - in other words when my application is running.

The fact that everything works in a simpler scenario merely proves that the basic processor and LTDC setup is correct - I already know this.

The issue is that this only occurs on the "V" part and not on the "Y".

[waclawek.jan]

Okay, but did you use HSI as the primary source, or something else?

JW