Old Synopsys IP databook descriptions in H7 reference manuals

[srvanloon]

Hello,

 

After debugging for a customer, I have found that all ST H7 related reference manuals are simply copy/pasting old Synopsys IP settings of the USB HS and/or FS core from an ancient databook. The new driver for the H7RS is again a copy of an existing driver to 'make things work'. Why is there no initiaive to develop a generic driver that works on all versions of the micro STM32F0-7, STM32H5-7, etc and maintain so many variants of the same sauce ?

For example the HFIR timing seems to be off by one. Synopsys acknowledged that their previous databooks had an  error and ST seems to simply put forward the same error even on new released cores. So my question is basically: How much can we take your reference manuals for granted when it comes to what is actually inside the MCU ? It's sort of frustrating if you do not have the accurate docs in front of you, especially nitty gritty timing issues. 

The Linux drivers for this DWC2 core obviously fixed this one issue and should be carried through to all ST releases to fix potential jitter errors on the USB bus. Does anybody work with an USB analyzer and properly check timings of driver releases ?

Reference to where Synopsys acknowledged the error is here: [PATCH v6 10/22] usb: dwc2: host: Properly set the HFIR (infradead.org). Synopsys maintains the driver in Linux and I guess I can take them as a proper source of information when it comes to their design and/or potential errata.

@st, Please fix your docs according to what is actually inside the core. The USB drivers can have an update as well by reading out the respective FIFO configurations  from the IP and prevent some 'magical' hardcoded values that often don't work on the core as they have a different FIFO size or what not. The HWCFG registers reflect most parameters hardcoded in the core itself so why not use them ? 

Sorry for this sort of rant but can someone at ST please comment why this is the case ?

 

Bas

[Tesla DeLorean]

A lot of the "complex" stuff has been third-party IP, so CAN, USB and ETHERNET/PTP, for a very long time

The "simpler" TIM, SPI and UART stuff being home-brewed

[srvanloon]

I get that, but that's no excuse not to pair the right documentation in their reference manuals matching with what they ship in the core itself I think.

Regarding the complex stuff, I am aware, I have worked on ST chips substantially the last few years including their Ethernet IP which comes from Synopsys as well. I Have developed a full firmware for H7 that runs a DOOH LED panel at full video frame rate (60Hz) using the H7 and their timers, SPI and USARTs, pretty awesome. Something that only FPGAs were able to do in the past!.

So I do not want to imply it's all bad. I simply state for the parts of the documents that they provide, and they didn't design in-house they should make sure it matches with what they deliver and even more keep it up to date in case of an errata by another design house.

[STOne-32]

Dear @srvanloon,

Welcome in our STCommunity, many thanks for spotting such inconsistencies between the reference manuals and real silicon behavior for user programming. Indeed, for time to market reasons and using proofed industry Peripheral , some of our high end USB controllers embedded in F2,F4, F7 / H7 etc.. are licensed  from our Partners , by the way including the main Cortex-M core. We will check versus latest DWC and back to you ASAP with our actions plans either to updated the errata’s of documentation or embed in the reference manuals .

much appreciated !

Ciao

STOne-32

[srvanloon]

Dear @STOne-32 ,

 

Much appreciated, I might have come off as a bit frustrated as there are more items to deal with regarding USB but happy this is being considered.

I am pulling my hair out so to say. Timing issues mixing with a real issue are distracting and can lead you to wrong conclusions.

Situation: USB HS using internal PHY in FS mode as Host.

While we use Zephyr OS and updated to the latest version of HAL/LL drivers we still observe CRC errors on the bus during normal runtime. The issue regarding the sleep clock on the HS PHY was found and we disabled it and that made the USB port sort of usable in Zephyr. We do however still observe SOF frame issues with CRC errors in them as mentioned before. The issue stops completely when we stop the ARM core. As if something runtime influence the core. I was not able to find a place in the code that could potentially influence the core. It even happens when the USB port is fully idle, while other parts of the GUI (TouchGFX, so DSI/LTDC are running as well) keep running.

Another indication was, on some boards it was so bad that I had to increase PLL3 to max 960 MHz output of the VCO then then divide it down to 48MHz for the USB core to get it more in line with what you would expect. The CRC errors on the bus became a lot less frequent but still visible.

Is there any hint to where this could be coming from or some avenue to go towards ? We run in SMPS mode, 400MHz Core speed, 16MHz HSE, STM32H747BI

Checked clocks with an active probe and R&S scope. Nothing seems really out of the ordinary. Noise levels seemed normal. My feeling was that the whole is very sensitive, spraying some cold spray on the MCU makes USB behave completely out of order which seems strange as the micro is spec'd to be able to run at -40C. Running USB on PLL1 seemed to make some difference. Scaling down the clock a bit to 384M for the ARM and run USB there but that was a non acceptable solution as the core runs within specs supposedly.

Any help here would be appreciated. We've raised the issue with our supplier (AVNet) but not much insightful info there.

Trace of what is happening:

[srvanloon]

As a reference, the core version number in the H7 is 3.30A, so they must have had the new databook and did not update their figures, tables and/or register values for at least the HFIR register :) Look at the date at when this post was made, 2016. We're in 2024 now and it seems no-one picked up on this discrepancy.