We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
There's a nasty bug hidden in USBD_HS_STM32F4xx.c driver code. It ALWAYS enables on-chip HSUSB PHY even if device is configured to use external PHY, making PB15 wrongly routed to PHY instead of another configured peripheral (SPI2 MOSI in my case).
Fix is very simple:
static int32_t USBD_DeviceConnect (void) { if (!(otg_hs_state & OTG_HS_USBD_DRIVER_POWERED) ) { return ARM_DRIVER_ERROR; } if ( otg_hs_state & OTG_HS_USBD_DRIVER_CONNECTED) { return ARM_DRIVER_OK; } OTG->DCTL &= ~OTG_HS_DCTL_SDIS; // Soft disconnect disabled #ifndef RTE_USB_OTG_HS_PHY OTG->GCCFG |= OTG_HS_GCCFG_PWRDWN; #endif otg_hs_state |= OTG_HS_USBD_DRIVER_CONNECTED; return ARM_DRIVER_OK; }
It caused me a lot of headache, so I would like to share it with anyone that might have the similar problem.
In latest DFP version v2.4.0 for STM32F400 pins are configured in OTG module and in that case if External ULPI phy is used pins for Embedded phy will not be configured for use with USB and should not interact with other peripherals.
In your case it is also odd if pins are selected in alternate function for SPI it should not have any interaction with USB even if PWRDWN is unnecessarily used.
Sorry, but you got it wrong. It is not pin configuration that is wrong. I configured pins correctly and it works as supposed as long as USB controller's PHY is disabled but as soon as you enable it, it tooks control over PB15 regardless of how GPIO pin function is programmed... I can send you sample project for MCBSTM32F400 and you can check it for yourself.
If GPIO alternate function is not selected to USB, USB phy enable disable shouldn't impact pins, anyways it will be corrected in new ST pack.
Yes, it should not, but it does... :-)