STM32F207 USB device with no VBUS monitoring

StefanoBettega1 · ‎2014-06-10

Posted on June 10, 2014 at 09:05

Hi all,

I'm modifying the VCP demo for STM32F207 to work without VBUS sensing, just using D+/D- for USB communications. As stated in RM0033 (page 935/1334 Doc ID 15403 Rev 5, chapter 29.5 USB peripheral): �The VBUS pin can be freed by disabling the VBUS sensing option. This is done by setting the NOVBUSSENS bit in the OTG_FS_GCCFG register. In this case the VBUS is considered internally to be always at VBUS valid level (5 V).�

So I modified my

usb_conf.h

and commented the line

&sharpdefine VBUS_SENSING_ENABLED

Code is perfeclty working on STM3220G evaluation board, but the same code loaded on our board does not work: device is not detected and inspecting USB_OTG_dev variable revelas that device does not change its status from the initial one.

I'm using USB FS, and the only difference between STM3220G board and our board is that PA9 pin is tied to VBUS only on STM3220G, while our board leaves it unconnected.

My question is: as VBUS is not sensed, how the USB peripheral detects host enumeration and exits the initialization state to become fully operative?

Thanks in advance,

Stefano

#usb-self-powered-devices-vbus #stm32-usb-device

StefanoBettega1 · ‎2014-06-12

Posted on June 12, 2014 at 09:05

Maybe I found the solution...

VBUS monitoring is not mandatory only for USB powered devices. For self powered devices, there is no way to detect cable connection/disconnection other than monitoring VBUS pin. Check also

http://www.lpcware.com/content/forum/vbus-input-required-device-mode

.

So now we have to manually detect VBUS presence, wiring VBUS to a free port and checking presence by reading pin value. My question is: when we detect VBUS present or missing, do we only need to call

USBD_DCD_INT_fops->DevConnected (pdev);

USBD_DCD_INT_fops->DevDisconnected (pdev);

as the library would normally do when automatically monitoring VBUS, or there are also other actions that must be performed (i.e. turning on/off the pull-up resistor on D+) ?

Thanks in advance,

Stefano

tpphysik · ‎2014-07-28

Posted on July 28, 2014 at 17:43

Have you managed to do it?

The reference manual says ''B-VBUS sensing enable (GCCFG/VBUSASEN)

It switches on/off the VBUS comparators associated with B-device operations. It must be

set when in B-device (USB peripheral) mode and during HNP.''

So I guess it always has to be set when using the usb this way manual vbus sensing is not possible, is it?

tomaskrueger · ‎2014-07-28

Posted on July 28, 2014 at 18:51

VBUS disable(HOST mode):

//#define VBUS_SENSING_ENABLED

....

/* configure charge pump IO */

//USB_OTG_BSP_ConfigVBUS(pdev);

/* Restart the Phy Clock */

.....

// enable disable the external charge pump

//USB_OTG_BSP_DriveVBUS(pdev, state);

// Turn on the Host port power.

StefanoBettega1 · ‎2014-08-29

Posted on August 29, 2014 at 15:12

Hi krueger.thomas.

I think the code you posted is related to an OTG host device. I don't need to turn on external VBUS power, as I'm creating an USB device, not an USB host. And even if I comment

VBUS_SENSING_ENABLED as you wrote, the only way to have the device enumerated and recognized by PC is to connect VBUS to PA9.

In fact if you look deeper in reference manual as reported by Václav, the USB peripheral state always use VBUS to change its internal status, so it's not possible to switch the internal state machine manually.

tjbuick · ‎2015-02-25

Posted on February 25, 2015 at 15:42

Hi Stefano,

I know this is a 6 month old thread now, but I was wondering if you managed to figure out a way to work around the lack of a PA9/VBUS connection in your design. I'm in the same situation as you are/were, and I'm using a BGA STM32F407, so no possibility of a hardware patch :(

My device is effectively bus powered, so it should be ok to comment out

#define VBUS_SENSING_ENABLED

as you have suggested in your first post.

However, as you also mentioned,

USBD_DCD_INT_fops->DevConnected (pdev);

USBD_DCD_INT_fops->DevDisconnected (pdev);

are never called without VBUS sense, so when connected to the PC it just results in an 'unknown device'. I'm guessing the library needs to be hacked a bit... but not sure where to start.

The interesting thing is that when BOOT0 is held high at power on, the micro successfully goes into bootloader mode (DFU) and connects properly with the PC. In this case, maybe the bootloader code sets it up as a USB host? If it is set up as a USB Device, then it must be possible to for us to do it as well...

Any info about what you ended up doing would be greatly appreciated! Thanks!

Tim