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"?

[berendi]

Yes, it was HSI, I don't need HSE.

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

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

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