H563/H573 - How to use the CC1,CC2 pins for GPIO and still get USB-MSC working

[VT_Jim]

Folks,

I started off with the H573i discovery board demo as reference for the MSC + SD card (with ThreadX). 

I don't have the Discovery board since in my application I needed those CC1, CC2 USBPD pins for something else.  So I ran a board of my own (using the H563ZIT6).  I'm using just micro-USB B connector, not USB-C.

I set up the project in Cube and pulled in all the segments from the demo for H573I.

But in CubeMX I have to disable the UCPD in order to get access the two pins I need.

I just left the USB enabled.

But it seems that there is no USB library setup properly if the UCPD is disabled.

Can someone tell me how to get the demo from the H573 to work if the CC1, CC2 pins are disabled in Cube and assigned as GPIO? 

I don't have to have the ThreadX but figured it might be helpful as my product develops.  

Thanks!

J

[VT_Jim]

@FBL I used the STM32H573I MSC + SD Card Demo (ThreadX) version as my reference starting project.  But I didn't have the Disco board.  I went straight to my own board.  I had blindly assumed that I could work without USB-C as the configuration.  I needed the pins for the CC1, CC2 for a different purpose.

But CubeMX does not permit you to use those pins for a different function if you want to use USB.  

The Cube so far has no means of making a regular USB project and bypass the UCPD demand for those pins. 

After making my BSP to reflect the hardware that I had on my board, I got the project to compile for my specific board configuration (IE: the H563 in the 144pin package)  mapped to my IO.

I got USB showing up as MSC to the PC but, it was not with UCPD enabled.  Cube just made a project that would always crash the moment it connected to the PC.  It took me a lot of time to hunt through the code to see that without the UCPD, there is no way it could work.  But that took away my pins I needed.

For now, I manually added in a hack to reassign those pins after  the UCPD Init assigns those pins.

I also had to add in my own call to enable the RPU (pullup for D+) to get it to be seen by the host PC.

CubeMX needs a config option on how to use the H5 series parts (and also the U5 series) without requiring USB-C (UCPD).  Or at a minimum, a way to not force the CC1, CC2 pins to USB while still ensuring the RPU call gets made to allow a cable attach detection.  

One of my products has molded enclosures that are still tooled for the USB-micro-B connectors.  I needed to migrate from the F769 to the U599 on that board and will likely face the same issue in Cube over the assignment of the CC1, CC2 and the UCPD.  

[AScha.3]

Just fyi : i have never activated ucpd , but USB working as it should, so dont activate it:

(here on H563ZI )

[VT_Jim]

@AScha In all my past projects/products, I've never had to enable the UCPD either.  As you say, not needed normally.  Those were also using FreeRTOS.

But for some reason, this need for UCPD might be the case for the specific combination of ThreadX + USBx and the newer U5, H5 chips it seems.  I'm not sure yet.  My past products were based on the F3, F7 based chips which didn't have the option of the UCPD.  

[AScha.3]

Also on my H563 with threadx and Usbx it's working, just need to enable power, as I needed to do, because Cube did not. Just try...

[VT_Jim]

That was how I spent my first two days of debugging in frustration.  I could not get it work work with UCPD disabled.  

But it is definitely useful to know USB-MSC it is working for others on this specific combo of chips and conventional USB.  So there is a good chance I just messed something up in my process of trying to replicate the USB-MSC + SD card demo from the H573I board but with disabled UCPD.  

I will experiment again later - like next week as I am way behind on testing other areas of my board.

Thanks again for your help and feedback!

[FBL]

@VT_Jim 

>CubeMX does not permit you to use those pins for a different function if you want to use USB. 

Would you please share a minimum of software setup to reproduce? I see no issue on myside. Drop your ioc here to investigate. Attached mine. There should be something missing. Make sure to use latest version of CubeMX.

[Nicolas P.]

Hello @VT_Jim ,

The use case you are setting up is a USBPD sink & USB device.

You are right saying that you don't need to configure the UCPD block in the H5 discovery board, because you are lucky. This boards has a TCPP03 protection chip (against shortcuts, over voltage, over temperature). And this chip embeds dead battery signals on CC lines. So even if the UCPD block is not active, on this board, thanks to the TCPP03 and its dead battery, on type C cable you will appear as a Type C consumer device.

As long as you don't need to negotiate power voltages, change data role, you will not need UCPD and the power delivery protocol.

Regards,

Nicolas

[VT_Jim]

@FBL could you send the IOC as the following:  USB-MSC (device), no UCPD, SDMMC1(SD Card-4bit), STM32H563ZIT6.  

That was the specific combo I was in need of.  The example you sent for the IOC turned out to be the Host mode.

While it did a Git commit the moment i had a working build, I didn't do any commits along the way as I ran through all my experiments to try and get it working.  I will have to see if I can get a reproduceable way to show the issue.  

It is as if there were missing files that weren't pulling in until I had the UCPD enabled.  Yet it was building. 

I will probably start this clean slate from a new IOC so that all the stuff I was trying gets cleared and that way I know I'm not pulling in files I don't need.  

[VT_Jim]

@Nicolas P. @FBL Question about the MCO1 signal output.  In my application I started it off at 20MHz output.  That worked perfectly.  Clean square-wave.   When I tried to go to 40MHz, the signal drops to only 300mV vs the 3V swing I get when at 20MHz.  I even removed a resistor I have in series with the output and probed the resistor pad.  I stepped through the divider range for the MCO1 output with using the PLL as the source.  At DIV10, great, DIV8, great, then at around DIV6, it becomes very strange and stalls to a very low output voltage on the pin.  All other aspects of operation in the system seem to continue to work normally.  So far it seems it is just the MCO1 pin that has an issue.  I can't find anything in the data sheets yet that would indicate that it is not meant for outputs over ~ 30MHz or so.  Can you think of what might make it drop the voltage swing level like this when under no load?

I will be using this MCO1 to clock a small FPGA that runs beside the STM32H563. 

I was hoping to be able to clock up to about 100MHz if I can using that pin.  

[VT_Jim]

@Nicolas P. @FBL Found the issue solution for the MCO1 startup.

If I use it as configured out of CubeMX, it places the MCO division and source setup in the SystemClock_Config which is the very first thing on code startup.  

There is some kind of internal problem where this MCO port fails to work correctly.

However - if I place the MCO config after the other peripherals are started at this location below, it works every time all the way up to my PLL1QCLK of 200MHz.  So either some other Init after SystemClock messes it up or there is a need for added delay before this MCO1 can start at all speeds.  When it failed out of Cube, it is at the correct  frequency but very low level.  at below about 25MHz it was working correctly out of Cube.