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.

[zoomcityzoom]

Posted on August 12, 2011 at 00:44

UPDATE: After further testing...

ISSUE 1: With PA9/OTG_FS_VBUS connected to +5V VBUS or VDD, upon entering DFU bootloader the PA9/OTG_FS_VBUS pin will ALWAYS sink 45 mA.

ISSUE 2: With a 10K pull-down on BOOT0, and application in flash, bootloader will sometimes be entered upon power-up. Once the bootloader is entered, the PA9/OTG_FS_VBUS pin will ALWAYS sink 45 mA.

It's a bit scary that the bootloader is being entered randomly. Anyone else able to confirm?

[zoomcityzoom]

Posted on August 12, 2011 at 00:55

It looks like the bootloader is entered upon power-up regardless of the state of BOOT0 if the STM32 is mass erased. Anyone able to confirm this? I don't see anything in the datasheet about this behavior.

[Nickname12657_O]

Posted on August 12, 2011 at 01:03

Dear stm32_fred,

This is not a usual case to have a sink of 45mA ( I beleive that in our DFU bootloader PA9 is used also with other protocols and may be grounded by software, but we need to check)  , and we are following the case thru our local support with your campany.   Due to time-shift between US east coast and our Headquarters in Europe, we will update you tomorrow your time.  Thanks for your understanding, Cheers, STOne-32.

[js23]

Posted on August 12, 2011 at 11:55

Unfortunately I am not using the F105 but the F107 - which should be identical when it comes to USB:

No, I cannot confirm both of you questions. I have never seen the boot loader to start randomly or with erased chip. (Just did a quick test with a F107 board, used the ST-link utility to erase the chip, then connected 10 times to the PC) To me it seems as if your device does not perform the reset correctly. Some wild speculation: Slow ramp up of VCC?

[zoomcityzoom]

Posted on August 12, 2011 at 17:35

Thank you STOne-32 and CrashAndBurn,

I found a design error that was causing the processor to randomly enter the bootloader. We have an LCD controller that shares the PC2/BOOT0 GPIO that was sometimes driving it's outputs during reset even though it's own reset line was pulled down. Apparently the LCD controller's reset initializes it's internal state but does not hold it's I/O in a tristate mode. Adding a pullup to the LCD controller's nRd line fixed the problem.

Next thing to do is to verify that the RX pins of the unused (USART1, USART2, CAN) bootloader peripherals are not floating. Perhaps this is what's causing the 45 mA current sink on PA9 when the DFU bootloader is active.

Why is it that you find the answers to your own mistakes just after posting to a public forum?

[Tesla DeLorean]

Posted on August 12, 2011 at 18:05

Why is it that you find the answers to your own mistakes just after posting to a public forum?

Sod's law : If something can turn out inconveniently it will

.

[zoomcityzoom]

Posted on August 12, 2011 at 19:10

Back to the main issue here:

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. However, with the PA9 pin sinking 45 mA while in DFU mode, a series resistor is not possible. 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.

Note: Since we are using DFU to connect to the bootloader, we have USART1_RX (PA10) and CAN2_RX (PB5) pulled low. We are using a 64-pin part which does not include USART2_RX (PD6). While in bootloader, I have confirmed the 45 mA current sink into PA9. Looking at the GPIO configuration registers via JTAG shows that PA9 is configured as output driving low while in DFU mode, yet if we disconnect +5V VBUS from PA9, the USB DFU interface is disabled.

[Nickname12657_O]

Posted on August 13, 2011 at 01:23

Hi stm32_fred,

We have more details for you : You can reproduce the issue of the 45mA with a simple code without involving USB : Use the evaluation board, boot from flash instead of bootloader, put any code in flash that configures  PA9  as Alternate Function Output Push-pull  , then run the code and apply to PA9 pin a 5Volts or VDD voltage you will see that 45mA.  This creates a race condition as in that configuration the USART1_TX pin is driving the Bus.   It seems a limitation in our bootloader that needs deep investigation as we are using USAR1 as well. More details are in Application Note AN2606. Cheers, STOne-32

[zoomcityzoom]

Posted on August 15, 2011 at 18:04

Thank you STOne-32 for your response.

Are you saying that in the bootloader, USART1 is enabled with PA9 configured as TX data output and at the same time to use DFU we need to apply +5V to

 PA9/OTG_FS_VBUS

 and that this is what is causing the 45 mA current sink into PA9?

As a result of this, are you saying that to use the bootloader DFU we may not protect PA9 input from +5 VBUS when VDD = 0V with a series resistor because the 45 mA current sink will drop the voltage across the series resistor and the DFU will not connect to USB?

What is your recommendation for protecting PA9 input from +5 VBUS while VDD = 0V?

What is your recommendation for protecting PA9 input from 45 mA current sink while bootloader DFU is active?

Thank you,