USB comms failure with Apple silicon (ARM) Mac

[davearoo]

Hi all,

I have a STM32F730I8K6 that handles USB comms (internal PHY, high-speed mode, 480 Mbps). The firmware is the 100% stock firmware generated by STM32CubeIDE, with only the USB peripheral enabled.

Connected to an Intel Mac, USB comms are reliable: performing GET_STATUS device requests in a tight loop works reliably.

Connected to an ARM (Apple silicon) Mac, USB comms are flaky: performing GET_STATUS device requests in a tight loop fails sporadically (kIOReturnNotResponding).

When the failure happens, the STM firmware is getting a USB_OTG_DIEPINT_TOC interrupt, which is described by the Reference Manual as:

"Indicates that the core has detected a timeout condition on the USB for the last IN token on this endpoint."

I'm not sure what to do with that information though. After several days experimenting, the only thing that's made a difference is forcing the device to enumerate as a full-speed device, using the OTG_DCFG.DSPD register; USB comms are reliable when doing that.

Does anyone have any suggestions on things to try to debug? (I've ordered a USB protocol analyzer, and also ordered a STM32F723E-DISCO board to see if it works with an ARM Mac.)

Thanks!

[Parawizard]

Did you end up sorting this out?

[davearoo]

I haven't solved this issue to my satisfaction, and I suspect it may not be fixable.

ST's own products have the same issue. For example the STLINK-V3MINIE (which uses a STM32F7 for USB comms) simply doesn't work with the internal USB ports on Apple silicon (ARM) MacBooks. (It does work through a hub.)

Additional reports:

• https://community.st.com/t5/stm32cubeprogrammer-mcus/stlink-v3-is-not-recognized-on-macbook-pro-with-m2/td-p/581483
• https://community.st.com/t5/stm32cubeprogrammer-mcus/stlink-v3-not-working-with-macbook-m2/td-p/641808
• https://community.st.com/t5/stm32-mcus-boards-and-hardware/st-link-v3-on-macbook-pro-m2-running-sonoma-14-4-only-works/td-p/665420
• https://community.st.com/t5/stm32-mcus-boards-and-hardware/cannot-reliably-connect-to-dev-board-from-macos-sonoma/td-p/679776
• https://community.st.com/t5/stm32-mcus-boards-and-hardware/help-starting-testing-stm32h747i-disco-on-macos-apple-silicon/m-p/676649

The root cause seems to be an incompatibility between the MacBook USB PHY and the STM32F7 USB 2.0 HS PHY.

The best workaround I've found so far is to use a different value for USB_HS_PHYC_TUNE_VALUE. I'm using 0xE043, which results in mostly-reliable USB comms. (Be sure to set the register to this value, don't bitwise-or it like the stock code does.) I've still seen a few comms failures with this value, but they're rare.

[Parawizard]

Thanks for the reply. I hope to see an official response from ST. One thread they said they were looking into a signalling issue with TI controllers.