I'm working on bringing up USB full-speed support on STM32F405.  My board does not include a USB power switch, VBus sensing, over current detection, or ID pin.

This commit add a config STM32_OTGFS_VBUS_ CONTROL which lets us selectively disable VBus sensing and control.  I also sneaked in a change to disable the configgpio call for the ID pin, which is only used in OTG mode which isn't supported yet.  The only pins that need to be initialized should be OTGFS_DP and OTGFS_DM.

These changes let a USB mouse enumerate on my platform if it's plugged in on power-up.  Plugging, unplugging, clicking, or moving the mouse cause NSH to stop responding.  Because I'm using the ramlog, I don't have useful debug messaging yet, so there's a lot more work I have to do to troubleshoot it or get my JTAG debugging set up, but these patches shouldn't hurt anything.  I'm hoping my issue is something simple I overlooked in configuration.

I'm planning to add similar changes for the OTGHS peripheral (using integrated full speed phy) but I still need to test those changes before submitting patches.
This commit is contained in:
Jeff 2017-08-07 10:24:31 -06:00 committed by Gregory Nutt
parent 1ac4848686
commit 4cbde22992
4 changed files with 22 additions and 4 deletions

View File

@ -6828,6 +6828,15 @@ config STM32_OTGFS_SOFINTR
---help---
Enable SOF interrupts. Why would you ever want to do that?
config STM32_OTGFS_VBUS_CONTROL
bool "Enable VBus Control"
default y
depends on USBHOST && STM32_OTGFS
---help---
Enable VBus control. Used when the board has VBus sensing and
a power switch for the OTG FS USB port. Disable this config
if the board lacks this USB VBus control circuitry.
endmenu
menu "USB HS Host Configuration"

View File

@ -5012,9 +5012,11 @@ static void stm32_vbusdrive(FAR struct stm32_usbhost_s *priv, bool state)
{
uint32_t regval;
#ifdef CONFIG_STM32_OTGFS_VBUS_CONTROL
/* Enable/disable the external charge pump */
stm32_usbhost_vbusdrive(0, state);
#endif
/* Turn on the Host port power. */
@ -5280,7 +5282,7 @@ static inline int stm32_hw_initialize(FAR struct stm32_usbhost_s *priv)
/* Deactivate the power down */
regval = (OTGFS_GCCFG_PWRDWN | OTGFS_GCCFG_VBUSASEN | OTGFS_GCCFG_VBUSBSEN);
#ifndef CONFIG_USBDEV_VBUSSENSING
#if !defined(CONFIG_USBDEV_VBUSSENSING) && !defined(CONFIG_STM32_OTGFS_VBUS_CONTROL)
regval |= OTGFS_GCCFG_NOVBUSSENS;
#endif
#ifdef CONFIG_STM32_OTGFS_SOFOUTPUT
@ -5383,7 +5385,9 @@ FAR struct usbhost_connection_s *stm32_otgfshost_initialize(int controller)
stm32_configgpio(GPIO_OTGFS_DM);
stm32_configgpio(GPIO_OTGFS_DP);
#ifdef CONFIG_USBDEV
stm32_configgpio(GPIO_OTGFS_ID); /* Only needed for OTG */
#endif
/* SOF output pin configuration is configurable */

View File

@ -280,7 +280,9 @@ extern "C"
*
***********************************************************************************/
#ifdef CONFIG_STM32_OTGFS_VBUS_CONTROL
void stm32_usbhost_vbusdrive(int iface, bool enable);
#endif
#undef EXTERN
#if defined(__cplusplus)

View File

@ -553,6 +553,9 @@ Configuration sub-directories
One remaining issue with the above is that when we fail to go to the TX
state, there is a lot of warning debug output. ANY debug output while
the Spirit is heavily loaded WILL cause failures and packet loss!
Perhaps using a RAMLOG would remedy this. But, even with these debug-
induced failures, all tests are running properly without application
level errors.
Perhaps using a RAMLOG would remedy this.
The TCP test beats the radio very hard and it is actually heartening
that there are no failures that lead to data loss in this environment.
I would say it is functional but fragile in this usage, but probably
robust in a less busy environment.