STM32F767 – USB Host FatFS works on FS but not on HS (internal FS PHY)

[MADHU2]

Hi,

I'm using an STM32F767 with both USB OTG FS and HS in Host mode.

• FS is working fine with USB MSC + FatFS, and I can create files on a USB stick.

• HS is set to use internal FS PHY (no external ULPI). It detects the pendrive (HOST_USER_CLASS_ACTIVE), but FatFS fails to create/open any file (f_mount or f_open returns FR_DISK_ERR).

This happens in both bare-metal and FreeRTOS.
If I disable FS, HS works fine. But when both are active, only FS works for file ops.

 

Is there any way to get FS and HS USB MSC + FatFS working together when HS uses internal FS PHY?

Any example or suggestion to fix this dual-port issue would be invaluable.

Thanks!

[Andrew Neil]

Please give details of your hardware - see: How to write your question to maximize your chances to find a solution.

[Ghofrane GSOURI]

Hello @MADHU2 

When HS uses the internal FS PHY, it shares the same PHY hardware as the FS controller. This means both cannot operate fully independently at the same time because the PHY is a shared resource.

Since the PHY is shared, only one host controller can use the internal FS PHY at a time.

Unfortunately, examples with both FS and HS active simultaneously using internal FS PHY are non-existent.

You can try to merge FS and HS examples carefully, but expect to handle PHY sharing issues manually.

THX

Ghofrane

[FBL]

Hi All,

@MADHU2  is using two independent controllers @Ghofrane GSOURI  

Here is an example using F7 as CDC device on HS instance and HID device on FS instance. If still facing issues with your implementations. You may drop the firmware to help you further. 

[MADHU2]

Hi,

I'm using an STM32F767 with both USB OTG FS and OTG HS configured in Host mode.

Hardware setup:

• FS port uses USB_OTG_FS_DM / DP

• HS port uses USB_OTG_HS_DM / DP

• HS is configured to use internal FS PHY (no external ULPI PHY)

• VBUS is connected to +5V externally, and VBUS sensing is disabled in CubeMX.

---

What works:

• On the FS port, everything works fine. I can mount the pendrive, create .txt/.csv files, and write 50 RTC timestamp logs to the file using FatFS. This works in both bare-metal and FreeRTOS.

---

What fails:

• On the HS port (internal FS PHY), the pendrive is detected, and HOST_USER_CLASS_ACTIVE is triggered.

• But FatFS fails to create or open the file (f_open() returns FR_DISK_ERR or fails silently).

• If I disable FS and use only HS, then HS works correctly.

• If I enable both, only FS works for file operations.

---

What I’ve already tried:

• Used heap_3.c and heap_5.c

• Increased FreeRTOS heap to 65535 and task stack to 2048

• USB Host task runs and calls MX_USB_HOST_Process()

• USB logging function calls f_mount(), f_open(), f_write(), f_close()

• Works on FS, fails on HS to create the file and open.

---

My Question:
Is there a known limitation when using both FS and HS USB Host ports with MSC + FatFS, especially when HS is running in internal FS PHY mode?

Has anyone successfully used FS and HS (internal FS PHY) at the same time for independent FatFS logging?

Thank you!

[MADHU2]

Hi @Ghofrane,

Thank you for the clarification — that makes a lot of sense.

So, to confirm: when using the HS port with the internal FS PHY, it shares the same hardware as the FS port, and therefore both can't be used independently at the same time for USB Host MSC.

That would explain why file operations fail on the HS port when FS is also enabled.

Just to clarify further:

• In my case, HS (with internal FS PHY) works perfectly when FS is disabled.

• FS also works on its own.

• But when both are active, only FS functions properly — as expected now based on your explanation.

If I want to support dual USB ports (e.g. two pendrives), I assume the only proper solution is to:

• Use FS (internal PHY) + HS (with external ULPI PHY)
  OR

• Use only one USB Host port (FS or HS) at a time, and detect/switch dynamically

Could you please confirm if this is the recommended and supported architecture?

Also — is there any:

• Example project,

• Application note,

• Reference document,
  or even community-shared solution showing how to switch USB host controllers (FS ↔ HS) dynamically when using the shared internal FS PHY?

It would be very helpful to understand how this could be managed properly in firmware — if supported at all.

Thanks again for the detailed response!

[Ghofrane GSOURI]

Hello @MADHU2 

Yes, your understanding is absolutely correct and aligns with the recommended and supported architecture for STM32F7 USB.

My colleague @FBL  will assist you with this point:

Also — is there any:

• Example project,

• Application note,

• Reference document,
  or even community-shared solution showing how to switch USB host controllers (FS ↔ HS) dynamically when using the shared internal FS PHY?

THX

Ghofrane

[MADHU2]

hi,
Thanks for the reply so he will reply in this forum, or I have to message him.

[MADHU2]

hello  @FBL

Could you please confirm if this is the recommended and supported architecture?

Also — is there any:

• Example project,

• Application note,

• Reference document,
  or even community-shared solution showing how to switch USB host controllers (FS ↔ HS) dynamically when using the shared internal FS PHY?

It would be very helpful to understand how this could be managed properly in firmware — if supported at all.

Thanks again for the detailed response!

[Ghofrane GSOURI]

Hello @MADHU2 

After double-checking, the STM32F7 USB_HS and USB_FS do not share the same PHY hardware. I was initially confused by the STM32MP1, which does share access to the PHY.

I apologize for any confusion caused.

The issue appears to be more related to FatFs rather than USB. Currently, I need to confirm whether FatFS can handle double instance registration. I will get back to you as soon as I have useful information that can help resolve the issue.

THX

Ghofrane