STM32F7: DIEPINT_TOC with ARM (Apple silicon) Mac

[davekeck]

Operating System

MacOS

Board

custom

Firmware

stm32f723disco

What happened ?

I'm running the stm32f723disco example on a custom board. (Actual chip: STM32F730I8K6.)

USB comms work reliably when connected to an Intel Mac.

USB comms are flaky when connected to an ARM Mac, in which case the USB_OTG_DIEPINT_TOC / DIEPINT_TOC interrupt is occurring on EP0. This causes TinyUSB to loop in handle_epin_irq() (because it never clears the DIEPINT_TOC interrupt). However it's my understanding that the DIEPINT_TOC interrupt shouldn't occur in the first place.

Here's a screenshot of my debugging session that shows that epin[0].diepint has DIEPINT_TOC set (bit 3). See debug console at the bottom:

This issue also occurs with stock STM32 firmware generated by STM32CubeIDE, which I posted about here:

https://community.st.com/t5/stm32-mcus-embedded-software/usb-comms-failure-with-apple-silicon-arm-mac/m-p/618571#M43842

I've ordered the official STM32F723E-DISCO hardware to verify that this isn't an issue with my custom board, as well as a USB protocol analyzer. I'll update this issue in a few days with my findings. I hope opening this issue isn't premature...

Issues related to DIEPINT_TOC interrupt: #139, #171

How to reproduce ?

Plug device into ARM Mac, and repeatedly issue GET_STATUS device requests. Eventually the DIEPINT_TOC interrupt will occur.

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

I can't access the logging on my custom board. I'll provide the logging once I test on the official STM32F723E-DISCO hardware.

Screenshots

No response

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[davekeck]

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 V3 devices have flaky USB when connected to ARM Macs? I'd expect lots of complaints if that were the case, but I haven't seen any.

I have a STLINK-V3MINIE arriving tomorrow so I'll test and provide an update.

[davekeck]

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.)

[hathach]

I don't have mac Mx machine to test with, for the record, are you using OTG HS or FS on F723 ? also which stock exampmle specifcialy e.g cdc_msc ?

[davekeck]

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:

diff --git a/src/portable/synopsys/dwc2/dcd_dwc2.c b/src/portable/synopsys/dwc2/dcd_dwc2.c
static void phy_hs_init(dwc2_regs_t* dwc2) {
...
-  dcfg |= DCFG_DSPD_HS << DCFG_DSPD_Pos;
+  dcfg |= DCFG_DSPD_FS_HSPHY << DCFG_DSPD_Pos; // Tell HS peripheral to operate in FS mode

This issue applies to all the TinyUSB examples; since basic control transfers are flaky, the device struggles to enumerate, and when it does successfully enumerate, a control transfer will fail before long. FWIW though I verified that claim with these TinyUSB examples: dfu, cdc_msc, hid_generic_inout, hid_composite, midi_test.

[davekeck]

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 as expected: the control transfers never fail and the loop continues indefinitely.

On an ARM Mac, a control transfer will fail with kIOReturnNotResponding after less than ~100 attempts (ie it typically takes less than a second).

[davekeck]

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 run the ST-USB-Issue-Repro program (which simply issues GET_STATUS device requests repeatedly), this issue occurs.

Here's an example ST-USB-Issue-Repro invocation:

% ./ST-USB-Issue-Repro 1155 14164
GetStatus control request succeeded (0)
GetStatus control request succeeded (1)
GetStatus control request succeeded (2)
GetStatus control request succeeded (3)
GetStatus control request succeeded (4)
Error: ControlRequest failed: (iokit/common) device not responding

I also confirmed that this failure disappears when connecting the STLINK-V3MINIE to an ARM Mac through a hub, or when the host is an Intel Mac.

[davekeck]

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 on a STLINK-V3MINIE:

I'll dig into that but if anyone has thoughts, let me know...

[davekeck]

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 inline void dwc2_phy_init(dwc2_regs_t* dwc2, uint8_t hs_phy_type) {
       // Control the tuning interface of the High Speed PHY
       // Use magic value (USB_HS_PHYC_TUNE_VALUE) from ST driver for F7
-      USB_HS_PHYC->USB_HS_PHYC_TUNE |= 0x00000F13U;
+      USB_HS_PHYC->USB_HS_PHYC_TUNE = 0;

But what's an appropriate value to use? My scope only goes up to 200MHz, so I'm not equipped to analyze the analog D+/D- signals...

[davekeck]

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 the LFSCAPEN bit (bit 2) to be retained, where LFSCAPEN is described by the reference manual as:

LFSCAPEN: Enables the Low Full Speed feedback capacitor.

This capacitor is presumably messing up our analog signals, which makes sense because it appears to be intended for low/full-speed mode, but we're in high-speed mode.

[davekeck]

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 left side of my ARM Mac. USB comms are still flaky when the device is connected to the USB port on the right side. 🤯

Presumably the signal integrity of the D+/D- signals still isn't great with the USB_HS_PHYC_TUNE magic value of 0xF13.

[davekeck]

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 device (a USB HS Kingston thumbdrive) versus the STLINK-V3MINIE.

The STLINK-V3MINIE looks a lot noisier by comparison:

[hathach]

thank you for your detail feedback, it is indeed confusing with these phy analog magic timing. I don't have anything to add or test, though please keep update the information. Maybe other could help.

[davekeck]

Additional info: this issue doesn't appear to occur on M1 Macs. So as of now:

• Broken: M3 Macs
• Working: M1, Intel Macs
• Untested: M2 Macs

I filed FB13481335 with Apple regarding this issue, but it's still unclear whether the problem is on the host side or device side (or both).

[davekeck]

A report of a similar issue (USB-C device works with M1 Mac, broken with M3 Mac):

https://forums.macrumors.com/threads/usb-c-problems-on-new-m3-max-macbook-pros.2410302/