STM32F105 PA9/OTG_FS_VBUS Issues

[zoomcityzoom]

Posted on August 11, 2011 at 21:21

ISSUE 1: PA9/OTG_FS_VBUS +5V Tolerance

When the STM32F105 is configured as a USB device, the PA9/OTG_FS_VBUS is used to detect the presense of a USB host. ST Micro evaluation designs show the PA9/OTG_FS_VBUS pin connected to +5 VBUS through a zero ohm resistor. There are two potential problems with this approach. The first potential problem is that the PA9/OTG_FS_VBUS input, although it is 5V tolerant, may be damaged (as per ST support) if connected to +5V when the STM32F105 VDD is 0V. This may occur in both self powered and host powered applications. This will occur in a self-powered application when power is switched off/unplugged while the USB connection to the Host is still active. This will occur in a host powered application during the time it takes the VDD regulator to come up to it's regulated output voltage. Some designers have recommended a series resistor between the PA9/OTG_FS_VBUS pin and +5V VBUS. See ISSUE 2. To avoid the potential to damage the PA9/OTG_FS_VBUS pin, ST support has recommeded connecting the pin to VDD instead. I have verified that this will work with USB application code as well as DFU bootloader mode. One of the problems with this approach is that you lose the ability to detect the presense of the USB host if you are a self-powered device. In that case, I think the only solution is to drive PA9/OTG_FS_VBUS input from the output of a +3V3 LDO (such as digikey AP7313-33SAG-7DICT-ND) which is powered from +5V VBUS.

ISSUE 2: PA9/OTG_FS_VBUS Current Sink

Take the evaluation design or your own design with the STM32F105 and put a milliamp-meter in-between PA9/OTG_FS_VBUS and +5V VBUS. Plug and unplug your USB connection to the host up to 50 times. Every once in a while, you'll see that the PA9/OTG_FS_VBUS input is sinking 45 mA. Connect the PA9/OTG_FS_VBUS pin to +3V3 VDD and you'll also measure 45 mA. This pin becomes a true 45 mA current sink. If you happen to be in DFU mode and running the DFUse demo application you'll see that you are in fact connected and the USB interface is still working properly. Disconnect one lead from your meter and reconnect and you'll see that the pin is still sinking 45 mA. The only way to stop this condition is to power down the STM32F105 and power up again or you may have to power cycle a few times. If you happen to have a 1K resistor in series with PA9/OTG_FS_VBUS and +5V VBUS when this current sink condition is active, the USB interface will not be active - no DFU boot loader, no USB device application code will work.

Here's an experiment I tried while PA9/OTG_FS_VBUS pin is exhibiting this 45 mA current sink behaviour and I am in DFU mode while connected to host running the DFUse application. I have a 0-100 ohm potentiometer in series with PA9/ORG_FS_VBUS and +3V3. If I set the series pot to 0 ohm, I measure 45 mA and USB is ACTIVE. If while I measure the V at PA9 while increasing the R, the USB will go inactive at PA9 V = 1.2V with 39 mA and 98 ohm R. While monitoring V at PA9, the USB will remain inactive until I decrease R such that PA9 V = 1.6V with a current into PA9 of 45 mA.

I'm waiting to hear back from ST support on this. Will the STM32F105 be damaged if our device is powered up in a server application and PA9/OTG_FS_VBUS pin is sinking 45 mA for 6 months straight? Should we switch to the STM32F103 and lose the USB DFU cabibility? Questions and more questions.

[Nickname12657_O]

Posted on August 16, 2011 at 00:08

Hi,

My answers below with [A] Cheers, STOne-32.

[Fleck]

Posted on August 16, 2011 at 11:04

Hi,

just want to chime in saying I can confirm this very issue. Unfortunately the

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F105 DFU - how much current does it draw on PA9 pin&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=227

where I asked if others had the same problem got lost in one of the forum crashes, but essentially it said the same thing: Use the bootlaoder from system memory in DFU mode and PA9 draws ~45mA from VBus. Also see

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F105 no boot loader connect via USB&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=512

, which links the problem to the quartz used (25MHz vs. 8MHz). The only way to get around the problem we found was to NOT use the internal bootloader. We decided to use the DFU bootloader from the example in the ST USB-FS library (thus wasting 12k of Flash memory) and it has been working well for over a year now. Thanks stm32_fred for bringing this up again and actually managing to get someone at ST to listen! Thanks STOne-32 for investigating this further! Hopefully we can finally expect to get a fix in future revisions. jens

[Nickname12657_O]

Posted on August 17, 2011 at 01:24

Dear all,

Unfortunately, There is no work-around . And our recommendation is to not use ST boot-loader with USB  on STM32F105/7 devices, but to use only other available Protocols such as UART1/2.

We are preparing to Issue a new Limitation on device errata-sheet for current version of Boot-loader.

Then, we are planning to fix the issue in next version of boot-loader.

Cheers,

STOne-32.

{STM32 Moderator}

[issa]

Posted on March 10, 2014 at 08:06

Hi STOne-32,

I use ST-bootloader with USB on STM32F105 microcontroller and I can't find any errata talking about this Issue.. Is this issue fixed ?thank you

[issa]

Posted on March 10, 2014 at 08:08

[myfunnymail]

Posted on April 21, 2014 at 13:47

http://www.st.com/web/en/resource/technical/document/application_note/CD00167594.pdf

''5.4.4 PA9 excessive power consumption when USB cable is plugged

in bootloader V2.0 Description When connecting an USB cable after booting from System-Memory mode, PA9 pin (connected to VBUS=5 V) is also shared with USART TX pin which is configured as alternate push-pull and forced to 0 since the USART peripheral is not yet clocked. As a consequence, a current higher than 25 mA is drained by PA9 I/O and may affect the I/O pad reliability. This limitation is fixed in bootloader version 2.1 by configuring PA9 as alternate function push-pull when a correct 0x7F is received on RX pin and the USART is clocked. Otherwise, PA9 is configured as alternate input floating.

Workaround

None.''