STM32H743 target running in OTG_HS1 mode (without USB PHY), run USB serial Full Speed thru USB OTG_HS_XXXX pins?

MScho.14 · ‎2019-01-15

Requirements:

1) Need all the HRTIM output pins (PC6, PC7, PC8, PA8, PA9, PA10, PA11, PA12, PG6 & PG7) for Power Supply design, where many are typically used for USB Full Speed serial OTG_FS_XXXX pins (PA9, PA10, PA11, PA12, PA4)…

Are following Assumptions true, if No, why? (Details please)

2) Only possible way to retain USB port serial Full Speed operation (don’t want / need ULPI interface: design devoid of external High Speed PHY, as design will also need these pins mapped to alternate functions). Therefore, just use USB OTG_HS_XXXX pins (PB12, PB13, PB14, PB15, PA4), they will function identical to OTG_FS_XXXX pins above when uC in OTG_HS1 mode (RM0433 figure 746)?

a. The USB OTG_HS_XXXX pins may be used / connected to existing external Full Speed serial USB circuit (identical to OTG_FS_XXXX pins) and may be programmed to function properly at USB serial Full Speed?

b. OTG_HS1 mode will support Full Speed USB operation, and does not require the remaining USB high speed ULPI pins to be selected and operational?

3) Existing USB Full Speed serial driver formerly used by OTG_FS_XXXX pins will need to be mapped to OTG_HS1 mode and OTG_HS_XXXX pins, with following major / minor changes? Help please!

4) How about USB Boot loader, what is it’s fate using OTG_HS1 mode and OTG_HS_XXXX pins?

5) Additional USB serial Full Speed relevant pitfalls that should be considered when using above design approach?

waclawek.jan · ‎2019-01-15

There is no OTG_HS1 *mode*. There are two completely separate OTG modules, and it's sad that ST can't name them properly (e.g. OTG1 and OTG2, so that the name is "speed-agnostic" thus unambiguous), inventing more and more confusing names for the same two modules across families and across documents...

So, yes, you can use OTG_HS1=OTG_HS (let's call it OTG1) with the OTG_HS_DP/OTG_HS_DM=PB15/PB14 pins (if you intend to use the module as device-only, you won't need the other pins). These are connected to the OTG1's internal FS PHY, so you don't need external PHY and the OTG1's ULPI pins are free for other use. The driver should be universal, good for both modules; the difference in which PHY (internal FS vs. external ULPI) is used is in setting two or three register-bitfields (OTG_GUSBCFG.PHYSEL and for device OTG_DCFG,DSPD) and according to the RM the OTG_HS2=OTG_FS (OTG2) module has identical setup (there are no registers marked as OTG1-only or OTG2-only, nor there are different defaults or some bits missing or read-only - no difference at all, only the ULPI pins are not brought out to the pinmatrix) so it needs to have set those fields for the internal FS PHY, too. The default bootloader's DFU mode is bound to the OTG2 pins so you can't use it; custom bootloader is just a user code so that's up to the user.

Disclaimer, I don't use the 'H7.

JW

View solution in original post

waclawek.jan · ‎2019-01-15

There is no OTG_HS1 *mode*. There are two completely separate OTG modules, and it's sad that ST can't name them properly (e.g. OTG1 and OTG2, so that the name is "speed-agnostic" thus unambiguous), inventing more and more confusing names for the same two modules across families and across documents...

So, yes, you can use OTG_HS1=OTG_HS (let's call it OTG1) with the OTG_HS_DP/OTG_HS_DM=PB15/PB14 pins (if you intend to use the module as device-only, you won't need the other pins). These are connected to the OTG1's internal FS PHY, so you don't need external PHY and the OTG1's ULPI pins are free for other use. The driver should be universal, good for both modules; the difference in which PHY (internal FS vs. external ULPI) is used is in setting two or three register-bitfields (OTG_GUSBCFG.PHYSEL and for device OTG_DCFG,DSPD) and according to the RM the OTG_HS2=OTG_FS (OTG2) module has identical setup (there are no registers marked as OTG1-only or OTG2-only, nor there are different defaults or some bits missing or read-only - no difference at all, only the ULPI pins are not brought out to the pinmatrix) so it needs to have set those fields for the internal FS PHY, too. The default bootloader's DFU mode is bound to the OTG2 pins so you can't use it; custom bootloader is just a user code so that's up to the user.

Disclaimer, I don't use the 'H7.

JW

MScho.14 · ‎2019-01-15

Hello JW,

Thank you very much for your time and detailed explanation, I will consider everything you said carefully and attempt due diligence before proceeding with new STM32H7 HW + SW design...

Cheers, MS