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.

[waclawek.jan]

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

JW

[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".

[berendi]

> 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.

What does it prove exactly? That firmware written for rev Y does not work on rev V, when used on a board made for rev Y.

> Something about the "V" is different

Yes. The differences can be found all over the datasheet, reference manual, errata, and there is an application note as well.

Lat but not least, the HAL library is different. It checks the revision a couple of times.

~/STM32Cube/Repository/STM32Cube_FW_H7_V1.7.0/Drivers/STM32H7xx_HAL_Driver$ rgrep REV_ID Inc Src|wc -l
33

OK, half of them are in the 753 AES module, but there is still a handful of them in the RCC code. Did you notice that the RCC register fields are slightly different?

HAL tries to make up for the difference between revisions, but does it succeed? Are there no bugs in HAL anymore?

When I've started my first project on a Nucleo-H743ZI2, I've configured it by mistake to use the non-existent HSE crystal. The generated SystemClock_Config() just silently ignored it, fell back to HSI for the system clock, and no clock for others. There was no check, it has just silently ignored the HAL_ERROR return values. That was a couple of months ago though, maybe HAL 1.5.0.

[waclawek.jan]

> Something about the "V" is different

Of course it is. It uses an adjusted technology (in addition to minor changes in logic, and probably different internal layout). The proof is, that its current consumption is somewhat higher at the same frequency. That might also mean more switching noise in the power lines, and that noise might couple into PLL.

> 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.

Exercising more logic introduces more switching noise into power lines AND INTO GROUND. The same applies for external circuitry, which is being exercised by the processor. And ground sees not only the internal switching spikes, but also the returns from the data lines between the circuits.

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

Yes it is - this is most probably not a software problem.

I know you don't want to hear that you may have a problematic hardware and possibly facing a board redesign, but what's the point in having high hopes in miracles to happen, instead of trying to find out the root case and eliminate it?

Looking into the 'H743 DS/RM, it appears, that contrary to other STM32, PLL is not in the analog supply domain but VDD domain - that makes things more complicated in this regard. Work towards as clean VDD as possible, tight decoupling, avoid common supply/grounds with other circuits. This may mean experimenting with cutting ground/power traces and replacing them with wires. Do you have a separate VDD/ground plane on your board?

JW

PS. Did you try to push the given PLL's VCO at its upper possible limit? I am taling about the PLL which feeds the LTDC. You may also want to output each PLL to a (MCO? as I've said I don't use H7) pin and compare their jitter.

[PMath.4]

"Did you try to push the given PLL's VCO at its upper possible limit? "

I've played with all variants of PLL settings. Bizarrely, it is most stable when at the upper limit. Anything mid-range is less stable and using any settings that should be better with RCC_PLL3VCOMEDIUM are much worse.

"Yes. The differences can be found all over the datasheet, reference manual, errata, and there is an application note as well."

I've been through all of these and coded for the differences where needed. I've been through the HAL code and checked it is correctly coding for the differences where applicable in the bits I'm using.

That firmware written for rev Y does not work on rev V, when used on a board made for rev Y."

There is no concept of a board made for one or the other - from a basic pinout and electrical perspective they should be interchangeable.

The problem is definitely electrical rather than code and unfortunately Jan is right I'm going to have to start hacking the PCB to try and find if I can overcome the problem. It is though very disappointing that the newer chip revision seems to have made things worse and I'm not the only one who has been struggling with "V"

IMHO ST have made a very poor decision to make a major revision to this chip rather than just doing a fix of critical errata. This compromises users who now have to deal with variants of firmware and apparently electrical changes and other than buying a specific Nucleo you can't predict which version of the chip you are going to get from any supplier. RS shipped me a "Y"s yesterday. JLC installed "V"s on the PCBs I had fabricated - aaagh!!!!

"

[berendi]

> I've been through all of these and coded for the differences where needed.

So there are even more possible points of failures in the code.

> from a basic pinout and electrical perspective they should be interchangeable

Apparently they are not. There are separate chapters for each rev in the datasheet. I think there is a reason for that.

> IMHO ST have made a very poor decision to make a major revision to this chip rather than just doing a fix of critical errata.

Agreed. But then they would be stuck with a 400 MHz MCU, that nobody would buy who started development after the proper 480 MHz part became available. Now they are desperately trying to back out somehow from that 10 years commitment, marketing the new 480 MHz part as a "revision".