2015-03-13 09:00 AM
I have a board based on the STM32F107 where the VBUS pin is unused, and USART1 TX is used on PA9. This has worked fine for me up until now, as I used a pin previously to define whether the CI should respond to USB or UART, and in general the device would be in either state. Because this worked so well, I idly put the issue of USB detection out of my mind and a few months later updated the PCB, now without the selection pin with the idea that the micro responds to whatever port the message came from.
Now the problem is that I can't actually use both ports simultaneously because every time I send something over the uart, the USB disconnects! What's more, I no longer have a concrete way to determine if the USB is connected...As mentioned in https://my.st.com/63552ec I have tried to disable VBUS sensing in the USB stack, but this simply disables the callback functions, the device still disconnects. I can confirm that this happens both on the PC (I can hear the disconnect sound) and the micro(the dive enters the disconnect callback if enabled).What's More I'm relatively certain this is not a firmware issue because I created a cubeMX project with the same uart/usb configuration and the code it generates does the same. What I'd like to know is if there is any way to tell the USB hardware to disregard what's happening on the uart pin. Barring that, is there any way to know if the device is connected without the VBUS? #stm32f107 #usb #usb #vbus2015-03-13 12:29 PM
> What I'd like to know is if there is any way to tell the USB hardware to disregard what's happening on the uart pin.
OTG_FS_GCCFG.NOVBUSSENS: VBUS sensing disable option (not documented on F1 reference manual, but on F2/F4 RM) Set this register bit at start-up initialization, and the ''VBUS'' pin is free from USB module. For example of Cube F1, the stack enable it here,\STM32Cube_FW_F1_V1.0.0\Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.c
HAL_StatusTypeDef USB_DevInit (USB_OTG_GlobalTypeDef *USBx, USB_OTG_CfgTypeDef cfg)
{
uint32_t index = 0;
for (index = 0; index <
15
; index++)
{
USBx->DIEPTXF[index] = 0;
}
/*Activate VBUS Sensing B */
USBx->GCCFG |= USB_OTG_GCCFG_VBUSBSEN;
if (cfg.vbus_sensing_enable == 0)
{
USBx->GCCFG |= USB_OTG_GCCFG_NOVBUSSENS; // <---------
}
> Barring that, is there any way to know if the device is connected without the VBUS?
You may assign another extra port pin (5V-tolerant) for VBUS change detection.
OTG_FS_GINTSTS.SRQINT is the VBUS ''valid'' interrupt flag.
On the stack, search for the reference to this bit. Move the ISR of the original to the GPIO pin, which is assigned to VBUS detection.
As of the Cube F1,
\STM32Cube_FW_F1_V1.0.0\Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_hal_pcd.c
void HAL_PCD_IRQHandler(PCD_HandleTypeDef *hpcd)
{
...
/* Handle Connection event Interrupt */
if(__HAL_PCD_GET_FLAG(hpcd, USB_OTG_GINTSTS_SRQINT))
{
HAL_PCD_ConnectCallback(hpcd);
__HAL_PCD_CLEAR_FLAG(hpcd, USB_OTG_GINTSTS_SRQINT);
}
Tsuneo
2015-03-14 04:57 AM
Thanks. I found this bit in the USB stack. it is actually being set correctly when the VBUS sensing is disabled in the usb_conf.h header. unfortunately this does not solve my problem. I'm thinking the reason the bit was not mentioned in the F1 reference guide is because its not actually implemented; i.e. the bit definition int he stack is purely for compatibility with the larger devices.
But whatever. I managed to inform the system to stop the uart when the USB is active, which was not as hard as I imaged. I put some breakpoints in the usb callbacks, and determined that the ''void USBD_USR_DeviceSuspended(void)'' gets called when the device is unplugged, and the ''void USBD_USR_DeviceConfigured(void)'' gets called when the USB is plugged in.2015-03-14 09:35 AM
If OTG_FS_GCCFG.NOVBUSSENS wouldn't work, VBUSBSEN bit is also available for this purpose.
\STM32Cube_FW_F1_V1.0.0\Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.c
HAL_StatusTypeDef USB_DevInit (USB_OTG_GlobalTypeDef *USBx, USB_OTG_CfgTypeDef cfg)
{
...
/*Activate VBUS Sensing B */
USBx->GCCFG |= USB_OTG_GCCFG_VBUSBSEN; // <----
Tsuneo
2015-03-15 11:44 PM
I tried fiddling with that bit earlier when I was looking at the code. The VBSUSEN A doesnt seem to do anything, but if I disable the VBUSEN B the device is not recognised when I plug it in... I had wondered at the time if a pull-up resistor on D+ would make it work, but I never tested that theory.