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

 

[AScha.3]

Hi,

so you want access SD-card , and then USB as MSC device ? (Its like a sd-card reader on USB ? )

[VT_Jim]

@AScha.3  I need to have this look like a microSD card reader to the user, but it is a memory controller device for a musical instrument.  Files get put into the SD via the USB.  

I have tested the SD (SDMMC1) is working fine.  It reads my cards.  I have also gotten the USB to show up on my PC as MSC device but with failure.  The event logs for Windows show that the USB has the correct Vendor ID, etc.  

But ThreadX crashes on me the moment I connect the USB cable.  

I selected to not use VBUS sensing.  My device is self powered and doesn't use the power from USB.

I had to manually add the line of code to initialize the RPU (pull up) on D+

So far, after more than a day of debugging, I know that drivers and event handlers are not working if the UCPD is not enabled.  But if I enable it, i lose the pins I need.

 

Can these H563/573 chips be used with the older USB ports without the UCPD (power delivery) and work within the CubeMX setup framework?

The IRQHandler is missing for something I believe.  But not sure how to tell which one?

 

 

 

 

 

[AScha.3]

>The IRQHandler is missing for something I believe.  But not sure how to tell which one?

I dont understand . :)

But dont start/use WWDG , its just a funny problem more, until your prog is working fine. THEN use watchdog.

+

Yes, you can use "old" library without Azure - if you prefer. But it should work with rtos also.

+

I have never tried MSC device on my H563-nucleo , but MSC host and Audio host . :) (much more problems...)

So i just can tell you : 

1. have a lot of ram space for threads... (otherwise crash)

2. maybe still the crazy error in Cube: it not enables power to USB !

If still the problem, add in stm32xxxx_hal_msp.c , at HAL_HCD_MspInit :

 

 /* Peripheral clock enable */
 __HAL_RCC_USB_CLK_ENABLE();
 /* USB_DRD_FS interrupt Init */
 /* USER CODE BEGIN USB_DRD_FS_MspInit 1 */
 HAL_PWREx_EnableVddUSB(); // enable power !!!!
 /* USB_OTG_HS interrupt Init */
 HAL_NVIC_SetPriority(USB_DRD_FS_IRQn, 6, 0);
 HAL_NVIC_EnableIRQ(USB_DRD_FS_IRQn);
 /* USER CODE END USB_DRD_FS_MspInit 1 */
 }

 

 

[VT_Jim]

Sorry for my confusion on your post above -

My MspInit already has the HAL_PWREx_EnableUSB.

The code you listed above matches what came out of CubeMX for me. 

So they must have fixed that bug you mentioned.

As I said - I do have the PC seeing this as a USB MSC and finds the correct VID/etc.  

I'm fairly confident the USB peripheral is powered. 

It is some interrupt handler that I must be missing somewhere.  

 

[VT_Jim]

@AScha.3 I checked and confirmed no watch dog is active.  It is not enabled in the CubeMX and doesn't appear in my code that I can find.  I believe that reference in the debug trace was that a RTOS watchdog service had an event that it trapped and when this event (interrupt) happens, it tosses the code into an assembly line forever loop within the TreadX assembly code.  In the code above that line it says this loop is to preserve the debug stack for unexpected Interrupts.  

I tried to enable the HAL_HCD_MspInit with a pre-compiler directive but when I do that, it flags a lot of missing files.  Any way to have Cube auto-generate this configuration with the older HCD enabled? 

Thanks for your help!

J

 

[AScha.3]

Sorry, what ? 

>enable the HAL_HCD_MspInit with a pre-compiler directive 

I showed you, how to write in xxxhal_msp.c (in your source directory)...so what you doing ???

+ its just the problem, HAL doing it wrong here. (Maybe corrected in later version, that i used.)

+> a lot of missing files --- should never happen, if you keep to what i showed.

[VT_Jim]

This is going to sound crazy but - I went into Cube and told it I have the UCPD peripheral and lost my two pins (CC1,CC2) that I wanted for something else.  

I recompiled and it still had the same crash, same problem.  

I tried reverting in CubeMX to compare which files changed.

I then went back to Cube and enabled the UCPD again and then compiled again. 

This time it worked!  I have the SD + the MSC finally working properly.  

There has to be some kind of issue over the order or sequence of setting things up that doesn't configure things correctly.  

I've committed a working copy and will see if I can narrow down what it was that changed in this process.

Such a huge sigh of relief however.  I thought i was going to have to make a new board spin just to switch to USB-C for this chip.  

Thanks for your help along the way in this! 

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

 

[FBL]

Hello @VT_Jim 

Have you tried the example provided in Cube?

STM32CubeH5/Projects/STM32H573I-DK/Applications/USBX/Ux_Host_MSC at main · STMicroelectronics/STM32CubeH5 · GitHub

You can disable UCPD port in IOC and regenerate. Please check again, it should compile and run. MX should import middleware without issues. If not, please provide your IOC file and screenshot crash.

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

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

 

[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

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

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