STM32H747 and USB DISK - how to make it work?

[HTD]

Discovery board: STM32H747I-DISCO.

OTG connected to P1 (HS).

First of all, there are two modes:

• EXTERNAL Phy
• Internal FS

EXTERNAL Phy is faster, Internal FS is slower. What does "external" mean?

Will it just work or not?

First I tried "Internal FS". Just doesn't work. Initialization with MX_USB_HOST_Init() passes, the f_mount() fails on reading first bytes from the disk. At the same time LD5 (overcurrent) is on, LD7 (VBUS) is off.

Then I tried "External Phy". Initialization passes. The same LED states, LD5 on, LD7 off.

Also I notice a weird thing: many pins that are NOT USED by USB_OTG_HS in the GPIO section were reset. I had to set them up manually. Including LCD_BL and LCD_RESET. My TIM3 CH1 output was also changed without a reason.

I lost all day for testing next to each and every option. I can't make the USB DISK work, what's worse, on one try I got LD7 on and LD5 off, but I can't get back to that state anymore.

To make it clear, I tested the OTG and USB disk on my Android phone and it works.

EDIT: After I fixed all that STM32CubeIDE has broken in GPIO configuration, now the device starts, both LD7 and LD5 are on, USB doesn't work.

ANOTHER UPDATE:

I fixed the VBUS problem. The next problem is when I try to make first read from the USB disk I get error, it's triggered at this exact point:

if ((phost->device.is_connected == 0U) ||
 (phost->gState != HOST_CLASS) ||
 (MSC_Handle->unit[lun].state != MSC_IDLE))
 {
 return USBH_FAIL;
 }

The phost->gState is HOST_DEV_WAIT_FOR_ATTACHMENT. Now why is that? The USB disk is already connected when the function is called. It's connected before the device is powered on.

I added HAL_Delay(1000) before calling f_open(), it still fails, but with state HOST_ENUMERATION.

[waclawek.jan]

http://www.efton.sk/STM32/gotcha/g105.html although what's USB there is mostly USB device, so only the "philosophical" part of it applies.

External PHY is, well, an extra chip, such as https://www.microchip.com/en-us/product/USB3320, which is connected to the STM32 OTG_HS through its ULPI interface. I don't know the STM32H747I-DISCO, read its manual, look at its schematics.

The OTG_HS does not have itself HS capability, but it has a built-in FS PHY, that's the internal FS. It then does not need to set up the ULPI pins in GPIO, rather it sets up its DP/DM pins (and maybe VBUS and ID). See datasheet.

Read the RM.

FS and HS in USB context https://en.wikipedia.org/wiki/USB_(Communications)#Signaling_rate_(transmission_rate) Read the USB spec.

JW

[HTD]

Here: USB3320 - it's installed on board. Pasted from the documentation.

The question is - WHY IS LD5 on? It is on even it's nothing connected to the P1 port. When I was doing previous tests it was off, now it's on all the time, have I somehow fried my board? I rather don't think so. BTW, when the board is reset, the LD5 goes off. During programming it goes off. It goes on shortly before LD7 indicating the VBUS.

[waclawek.jan]

Read the DS of the switch which lights it up (unless PJ1 is turned to output and low, which is probably not the intended operation and which you check by looking at content of GPIOJ registers). Find out what are the conditions of given output to go active etc.etc.

The point of my rant I gave link to was, that it's your code thus your responsibility, even if you've clicked and copypasted it.

I doubt anybody here is willing to debug this rather random combination of hardware and software. ST might be ready to jump in if you present significant purchasing power, as expressed in $M++.

JW

[HTD]

You were right about PJ1 - I chose the RANDOM pin for Drive_VBUS_HS option. It was PJ1. I changed it to another free RANDOM pin:

Now - LD5 is off, LD7 is on, so... I guess the power is OK.

Now about copying and pasting. I do not do it. However, I use code generator from STM32CubeIDE. People often rant on HAL drivers, but it's all a matter of time - I don't have time to write my low level drivers. I made a quite big project from scratch, learned the STM32H747 from zero. I used a lot of features, configured a lot of custom options, it's such a hog that I'm almost out of free pins on the board. Everything except the USB OTG works. That's the last single thing that doesn't work.

Of course I use a debugger to debug both my code and the drivers. But here... Excuse me, but the problem is a little beyond my experience and knowledge. That's why I ask.

BTW, I found a lot of bugs in STM32CubeIDE code generator and HAL drivers. I fixed most of them. I fixed broken I2C driver (at least to a point where it's kind of usable, it still depends on spin wait on some features that is terribly wrong), I fixed GPIO mayhem generated when USB_OTG_HS External HS is used. I fixed the default memory caching setting that causes HAL DMA code to break. I fixed broken animations in TouchGFX. I don't use automatic clock settings solver - it doesn't work properly, I configured the clocks manually. So - let's say I at least try to do my homework.

Now about the hardware - it's Discovery Kit. Nothing else. Well - a USB pendrive, tested with my phone, it works. The STM32H747I-DISCO was probably tested, they wouldn't release it if something didn't work in it. I'm still convinced that the OTG should work as expected, however, there's something I'm missing here. Now I have VBUS power, no conflicts on pins, proper clock provided (48MHz), everything initialized - it still doesn't work.

Maybe I shouldn't specify just a random GPIO for the Drive_VBUS_HS feature? But what pin should it be? I can't find it in any documentation. There is a similar feature to SD Card. The pin is specified in the manual. It's SD Detect pin. It's both on the schematics and in the description. But for Drive_VBUS_HS - even Google finds nothing.

[waclawek.jan]

> Now about copying and pasting. I do not do it. However, I use code generator from STM32CubeIDE.

That's the same, or maybe even worse.

> Of course I use a debugger to debug both my code and the drivers. But here... Excuse me, but the > problem is a little beyond my experience and knowledge. That's why I ask.

The problem is so extensive that there's no simple answer. That's why I wrote that rant.

> USB pendrive, tested with my phone, it works

Oh boy. Your phone has at least an order of magnitude more code to handle that "pendrive" than what you get with Cube. It's not Cube's fault, the issue is complex and the simplistic solution "usually works". See e.g. https://community.st.com/s/question/0D53W00001hiEFCSA2/need-3-cost-effective-usb-ports around middle of that thread.

> Maybe I shouldn't specify just a random GPIO for the Drive_VBUS_HS feature?

Most probably not. It's there for some reason, isn't it. What does that feature do? Where is it used in the code? I am not interested, you should ask yourself these questions.

JW

[HTD]

https://community.st.com/s/question/0D53W00000kvL2YSAU/warning-during-stm3cubemx-setting-in-usbhost-on-platform-setting-tab

According to the answer - any GPIO pin. So power's OK, clock's OK.

> That's the same, or maybe even worse.

Tell it to the STM32CubeIDE and TouchGFX devs ;) But well, you have a point here, the code cannot be trusted blindly, it has some bugs. Sometimes they are easy to spot, sometimes it takes a couple of nights. Still quicker than coding everything manually.