Dave Keck

I confirmed that this issue occurs on the stock STM32F723E-DISCO board running the stock stm32f723disco example. It looks like the STLINK-V3MINIE boards have a STM32F723 too, so do all STLink...

Also, this issue disappears when the device is attached to the ARM Mac through a USB-C hub (instead of attached directly to the ARM Mac.)

This issue occurs when using the OTG HS peripheral on the STM32F7. Interestingly the issue disappears when configuring the OTG HS peripheral to operate in full-speed mode with this change:...

Here's the program I'm using to reproduce the issue on an ARM Mac: https://github.com/davekeck/ST-USB-Issue-Repro/blob/master/ST-USB-Issue-Repro.mm It simply issues `GET_STATUS` device requests in a loop. On an Intel Mac, this program works...

I confirmed that the stock STLINK-V3MINIE (which has the STM32F723 and uses the OTG HS peripheral) also has this issue. If you plug a STLINK-V3MINIE into an ARM Mac and...

I just got my protocol analyzer set up about 3 seconds ago, but here are the working (Intel host, ARM host) vs failing (ARM host) traces when performing a `GET_STATUS`...

Good news: setting `USB_HS_PHYC_TUNE` to 0 fixes this issue, so that's a strong indicator that this issue is in the analog domain: ``` +++ b/src/portable/synopsys/dwc2/dwc2_stm32.h @@ -197,7 +197,7 @@ static...

The root cause appears to be that we're or'ing the `USB_HS_PHYC_TUNE` register with the magic value, instead of setting `USB_HS_PHYC_TUNE` *to* the magic value. This causes the default value of...

Upon further testing, the assign-to-0xF13-instead-of-oring-with-0xF13 solution (which has the effect of clearing the `LFSCAPEN` bit) only fixes USB comms when the device is connected to the USB ports on the...

I took a look at the D+ / D- signals with a 800 MHz diffprobe. My scope only goes to 200 MHz, so I'm comparing the signals between a good...