Defines TUP_RHPORT_HIGHSPEED for OPT_MCU_STM32H7

[ibeckermayer]

Describe the PR
Adds a necessary define for OPT_MCU_STM32H7

Additional context
I'm attempting to get tusb running on the STM32H7B3I-DK. While this doesn't totally solve my issues, I did notice that without this #define, if I had

// tusb_config.h
#define CFG_TUD_MAX_SPEED OPT_MODE_DEFAULT_SPEED ///< Default (max) speed supported by MCU

Then I would wind up with TUD_OPT_HIGH_SPEED == 0

tinyusb/src/tusb_option.h

Line 302 in 8b1e40c

#define TUD_OPT_HIGH_SPEED (CFG_TUD_MAX_SPEED ? (CFG_TUD_MAX_SPEED & OPT_MODE_HIGH_SPEED) : TUP_RHPORT_HIGHSPEED)

which would ultimately cause phy_fs_init to be called:

tinyusb/src/portable/synopsys/dwc2/dcd_dwc2.c

Lines 664 to 668 in 8b1e40c

	if (phy_hs_supported(dwc2)) {
	phy_hs_init(dwc2); // Highspeed
	} else {
	phy_fs_init(dwc2); // core does not support highspeed or hs phy is not present
	}

Unfortunately I don't have any of the supported h7 boards to double check this against, however so long as they support both FS/HS I believe this change is correct for them. There also seems to still be a major bug in getting things to work with my h7b3i board, so I will keep this as a draft for now until someone has a chance to test it with the boards that it should work properly for.

[ibeckermayer]

In debugging this further, I've found that the STM32H7B3LI MCU which is on this board spits out the following dwc2 configuration values:

guid, gsnpsid, ghwcfg1, ghwcfg2, ghwcfg3, ghwcfg4
0x00002300, 0x4F54330A, 0x00000000, 0x229FE190, 0x03B8D2E8, 0xE3F00030

These are identical to those listed in the ST H743/H750 column of dwc2_info.md.

---

I took out Wireshark and identified something suspicious:

In response to the first URB_BULK in (submitted) Request, I find

In particular this kiOReturnOverrun suggests some sort of buffer overflow or a related error in the MacOS USB driver.

For comparison here is a success transfer from the same app running on my U5 board

---

This is essentially the net_lwip_webserver app running with USE_ECM defined and the following prepended to the tusb_config.h

#define CFG_TUSB_MCU                 OPT_MCU_STM32H7
#define CFG_TUSB_OS                  OPT_OS_NONE
#define BOARD_DEVICE_RHPORT_SPEED    OPT_MODE_HIGH_SPEED
#define BOARD_DEVICE_RHPORT_NUM      1
#define BOARD_TUD_RHPORT             BOARD_DEVICE_RHPORT_NUM
#define CFG_TUSB_RHPORT1_MODE        (OPT_MODE_DEVICE | OPT_MODE_HIGH_SPEED)

@hathach / @HiFiPhile, if either of you happen to have a H743/H750 on hand, it could be worth checking if you can get that app running successfully on them (time permitting of course, I recognize you have competing priorities).

[hathach]

H7 does not has on-chip HS PHY, only FS. Therefore the current setting is correct.

[hathach]

@hathach / @HiFiPhile, if either of you happen to have a H743/H750 on hand, it could be worth checking if you can get that app running successfully on them (time permitting of course, I recognize you have competing priorities).

my H743 eval board running just fine, with either OTG FS and HS with external PHY

[ibeckermayer]

@hathach thanks for checking! Very much appreciated. In that case it must be some incompatibility with the h7b3 that I've yet to surface. I did manage to get hs to init without this change, I just needed to clean some cruft out of my tusb_config.h. I'll keep plugging away at the b3 on my own time and update the repo once I crack it.