NUCLEO H7S3L8 USB HS CDC Standalone example, stuck on USBPD_DPM_Run()

[simo zz]

Hi,

I am trying to setup an USB HS CDC example with NUCLEO-H7S3L8.

After setting up the projects for both CDC_Standalone and NUCLEO-H7S3L8 board example (for the latter I manually enabled the USB HS Device from CubeMX), I successfully ran each example to run from the external OSPI memory connected to the XSPI2 port.

STM32CubeMX standalone version is 6.13.0, while STM32CubeIDE version is 1.17.0.

STM32H7RS package version is the STM32Cube_FW_H7RS_V1.1.0.

1) I understand that setting up the CDC_Standalone example should result in a working example, but it does not.

2) The USPD interface is an TCPP03-M20, the BSP included in the board example (not the CDC_Standalone example) comes with a driver for this device which I understand it is automatically used by quickly looking at the code, but it seems it is not working neither.

"Not working" means that the USB device is not detected from the PC.

So for both cases, the function USBPD_DPM_Run() called into the main while loop hangs the execution of the firmware.

Is this behavior a known issue?

Is it needed some manual modification I am not aware of?

Thanks in advance for any hint.

s.

EDIT: I have attached the ioc file I am using.

[Dor_RH]

Hello @simo zz,

Have you tried the following application CDC_Standalone available in STM32CubeH7RS :

It includes an .ioc file and could be useful for your implementation.

I hope my answer has helped you. When your question is answered, please select this topic as solution that answered you, it will help others find that answer faster.

Thanks for your contribution.

Dor_RH

[simo zz]

Hello @Dor_RH,

The CDC_Standalone ioc I am using is already taken from the STM32CubeH7RS pack, saved to a custom home directory to do not "contaminate" the original one provided with the pack.

I have the feeling that the example is incomplete and wrong for setting up the USB HS.

For example, looking at the board schematics, TCPP03 is connected to ADC1 INP6 PF12, while the original CDC_Standalone  ioc enables INP0 on PA0.

Also, TCPP03 is connected to I2C3, while the original CDC_Standalone ioc file uses I2C2.

These are not the only differences between schematics and ioc file..

s.

[simo zz]

Hello @Dor_RH ,

Could you please share more info about how to correctly setup the CDC_Standalone example ?

As I wrote in my previous post, I think the original ioc file is missing some setup:

1) The board uses ADC1 and ADC2 connected to the Tcpp03 USB C power manager, while the ioc file uses ADC1.

2) I2C3 is used in the board with Tcpp03 communication, while I2C2 only is enabled into the ioc.

Also,  in addition to USPD and USB Device middle wares, I don't understand if it is required to enable TCPP application with or without RTOS..

For the tests I have done, the application remains stuck into USBPD_DPM_Run, and this function is not inserted into the main loop if RTOS is enabled. If not, the USB setup fails in USB_CoreReset (with or without the USB regulator enabled)... Of course I am quiet confused.

The CDC_Standalone readme file says:

1) It is mandatory to check that the jumper below is connected: JP4 (USB-PD)

But there is no jumper JP4 on NUCLEO-H7S3L8.

2) The DTCM (0x20000000) memory region should not be used by application in case USB DMA is enabled

3) Should make sure to configure the USB pool memory region with attribute "Non-Cacheable" to ensure coherency between CPU and USB DMA

Not sure how to set 2) and 3) in the CubeMX tabs. Should these option already set as default into the ioc file?

Definitely it seems that the example is not provided as ready-to-use in a few minutes, and it's hard to me to believe I have to implement the drivers from scratch.

Any hint will be appreciated.

Thanks,

s.

[Dor_RH]

Hello @simo zz,

• You can check the schematic of the NUCLEO H7S3L8 (Link : here) to better understand the board's connectivity.
• USBPD: is required to enable TCPP.
• For the jumper, you can use JP3.
• For the MPU configuration, there are parts that are included in the template and are generated by default by STM32CubeMX.

I hope my answer has helped you. When your question is answered, please select this topic as solution that answered you, it will help others find that answer faster.

Thanks for your contribution.

Dor_RH

[simo zz]

Hello @Dor_RH,

I am already checking the schematics as you may already read from my first post. OK for JP3, I assumed this but the readme is wrong.

I also already have enabled TCPP with USBPD. In almost every attempt, compiling results in missing sources or errors. God knows what STM32CubeMX does in background...

No way this example works for USB HS Device as it is provided, even more without a simple how to guide.

In addition, it is clear that asking clarifications regarding this example it's a huge waste of time.

Regards,

s.

[simo zz]

I finally managed to bring up CDC USB HS device port on NUCLEO-H7S3L8, after manual modifications to the sources.

s.

[b4shful]

---

@simo zz wrote:
...

The CDC_Standalone readme file says:

1) It is mandatory to check that the jumper below is connected: JP4 (USB-PD)

But there is no jumper JP4 on NUCLEO-H7S3L8.

...

---

With regards to this part, I submitted this as an issue on GitHub: https://github.com/STMicroelectronics/STM32CubeH7RS/issues/7

The provided .ioc files are, honestly, not very useful given the fact that I have found simply opening some of the ST provided .ioc files in CubeMX and regenerating the code can cause the entire project to fail. Whether it be by build error, error during flashing etc. Even when on seemingly the same version of the MCU Pack (e.g STM32CubeH7RS 1.2.0) and the latest versions of CubeIDE/CubeMX, the results and behaviour of the code generation is inconsistent and CubeMX's black box mechanism of operation is indecipherable.

That's not even mentioning the fact that if you don't want it to dump all of its code in a couple of files and completely clog up main.c, you check "Generate peripheral initialization as a pair of '.c /' h ' files per peripheral" in CubeMX Project Manager->Code Generation, which is almost a necessity to actually understand what it's doing in my opinion. Yet, I discovered recently that for a bunch of stuff on this chip (MX_HPDMA1_Init() and similar, a lot of peripheral specific MspInit functions, almost the entirety of the GPIO inits, timers, clock enables for certain peripherals, to name a few), generating with the separated pair of init code files per-peripheral option checked will cause it to just completely leave out chunks of important code (like the stuff mentioned above)! But it generates the correct code just fine (sometimes) if you don't use the separated init code option?! Switching back and forth doesn't really work so what you end up doing is cloning the project's CubeMX .ioc file to a new folder, opening the cloned .ioc file, disabling the "separate pair of files" option, regenerating code (making sure it's in an empty folder, if you cloned the other project files it might not actually regenerate properly), and then manually scouring through a diff of the two projects (which should be functionally the exact same just with different structures and locations) to find what's missing!

Back on the topic of the USB examples, there's so much confusing and conflicting information online that it's hard to know how it actually works. For example the NUCLEO-H7S3L8 has a TCPP03 chip on the board itself, but there's practically no explanation on what the USBPD middleware does, whether it's needed for a basic CDC setup, and whether or not the X-CUBE-TCPP middleware needs to get involved with this? I thought X-CUBE-TCPP was for the expansion boards where you're adding a TCPP03 to a board that doesn't have it. It doesn't mention NUCLEO-H7S3L8 anywhere on the X-CUBE-TCPP website (https://www.st.com/en/embedded-software/x-cube-tcpp.html) or the X-CUBE-TCPP data brief (DB4442), all indications would suggest that it's only intended for the USB PD expansion boards and not boards like the NUCLEO-H7S3L8 which have an on-board TCPP03 via I2C3 and on-board USB C ports, I would hope so. Maybe the USBPD middleware in CubeMX fulfils this purpose for this board - but it's so hard to find info on what that middleware does or if it's needed or not for a simple USB CDC device config (and getting power from the host).

It kind of feels like I am being punished for using CubeMX... I know the standard response to this is "CubeMX is for fast prototyping and initialisation but for production quality code you will want to write all initialisation code on your own and structure it your own way". That is all well and good but it seems like the development that has been put into CubeMX has come at the expense of literally any other documentation. Especially when it comes to newer or more niche peripherals, often the only way aside from trawling through the header files hoping you're looking in the right place is to get CubeMX to generate init code for it and see how it's doing it. But CubeMX is a black box and it behaves inconsistently, so when you can't trust what it's outputting you also can't trust/can't know for certain whether what it outputted is really what you need to do to initialise a peripheral, or if a necessary part is missing from what it generated. Sometimes all you want to know is how to enable something or configure something (let's say you want to enable a timer to help with execution timing/performance analysis), and sometimes CubeMX will quickly spit out what you need without any side effects and let you get on with whatever you were doing. But sometimes you will get burned and spend hours upon hours debugging only to realise the problem is in CubeMX, and completely lose your flow, slowing down your development and getting in your way (which is the opposite of what CubeMX is supposed to be doing).

I don't know what the solution is really (although a lot of threads talking about its problems seem to get responses from non-employee high ranking forum members being like "simple, just don't use CubeMX", and sometimes not in a good-faith helpful tone but a much more condescending one) - I think they should just open source it, but I have a suspicion that the CubeMX codebase might be unbelievably bloated spaghetti code and not something they would want to release in the wild(that last part isn't a jab at ST - plenty of organisations who create high quality code still end up with a "problem child" project!). If it was at least source available in some way, we could look into the black box and see what it's supposed to be doing, but for now all we can do is use the GUI to configure the inputs to the black box, press generate, and pray that it outputs something half usable.

[simo zz]

Hello @b4shful ,

The solution, as far as I remember and that's how I am working on, was to use the sequencer lib from other middlewares. This is used for USBPD monitor tasking. I remember that after using that lib, the CDC started working. No RTOS nothing else.

In addition to the incomplete ioc file (a very well written tutorial would be fine for such projects), the difficulties arise with STM32CubeMX being buggy: wrong Makefiles generation (from syntax to incomplete paths to missing includes and sources instantiation for compilation), different behavior from saving the project using the "Save as" option vs manually copying the directory vs only copying the ioc file etc... This is very frustrating and I managed as "keep calm and ...". Note that I don't use STM32CubeIDE (just its GDB server), so I use Makefile type project.

Actually I don't even use STM32CubeMX any more. Just read the TRM.

I know that developing a SW which should fit all the available configuration is quiet hard, but definitely the STM32CubeMX seems to be poorly tested under the circumstances just mentioned.

Regards,

s.