Associate III

Solved

DP ALWAYS Pulled High (UP)?

Forum|Forum|7 years ago
August 16, 2019
6 replies
2352 views

Hello All,

I am currently working on a USB device that supplies power (Chip = STM32F765). I am attempting to have this device be connected and unrecognized while in stop or standby mode and I am running into the unfortunate fact that the DP line has an embedded pullup resistor on it. Even when I configure it as a GPIO input with a pulldown, the pull up and pulldown divide the voltage and it ends up remaining relatively high, which means that the pullup is physically before the alternate function mux when coming into the pin from outside of the chip.

Having the DP line always high makes re-enumerating as a device when coming out of stop and standby mode difficult, because the connected host does not recognize that a new device has been connected. It already tried and failed to enumerate the device while it was asleep (because it sees the pullup when the device is asleep), so it doesn't retry enumeration when it wakes. If I could have it fall asleep with no pull-up, that would be ideal. The line is specifically PA12.

(EDIT: After speaking with the original hardware engineer, a board part that was thought to be ESD protection actually contained a pull-up resistor. Shorting this part solved the issue)

Does anyone have any ideas?

Thanks,

Zach

This topic has been closed for replies.

Best answer by ZThat

Thanks JW,

After discussing with the original hardware engineer we realized that a part on the board that was thought to be ESD protection actually contained a pull-up resistor as well. Shorting this part solved the issue. Thanks for the updated information.

All the best,

Zach

Uwe Bonnes

Chief

Did you look at the SDIS bit in OTG_DCTL?

ZThatAuthor

Associate III

I have. Flipping that seems to disconnect one of the pullups, but leaves one on. I can tell because

A) the pin stays high

B) I connect an external pull down, and when I flip the bit the drop across the external pulldown changes, effectively making it a divider and leaving the pin between high and low

ZThatAuthor

Associate III

I found a hard fought solution. I will provide some explanation to prove why this solution is necessary, but it ends up being relatively easy to implement.

A big part of the problem is that when you stop USB and de-initialize the core, you still do not have control over the pin. You can try to make it an output and drain the pin low and you will not be able to because the FS core remains in control. In order to do such a thing, you need to toggle the GCCFG bit after deinitializing the FS core, which is not done automatically in the HAL deinitialize function. This can be done as follows

USB_OTG_FS->GCCFG &= ~(USB_OTG_GCCFG_PWRDWN);

Once you have done this, you can then reconfigure the pin as a GPIO push pull output and set it low. This will force the line low, causing your host to finally see a disconnect. Re-initializing the USB will then tell the host to re-enumerate the device.

waclawek.jan

Super User

> Flipping [SDIS] seems to disconnect one of the pullups, but leaves one on.

What other pullup? There should be just one pullup in the OTG module on DP, controlled by SDIS.

> you still do not have control over the pin

Yes, this is a long-known gotcha, discussed here several times, long ago; unfortunately, ST is not keen to acknowledge it and make the changes across all parts' related documents.

https://community.st.com/s/question/0D50X00009XkXpCSAV/cannot-deinitialize-usb-host-pull-down-on-stm32f407

https://community.st.com/s/question/0D50X00009XkXJZSA3/deinitialize-usbotgfs

JW

ZThatAuthorBest answer

Associate III

Thanks JW,

After discussing with the original hardware engineer we realized that a part on the board that was thought to be ESD protection actually contained a pull-up resistor as well. Shorting this part solved the issue. Thanks for the updated information.

All the best,

Zach

waclawek.jan

Super User

Zach,

thanks for coming back with the result.

Please mark your post as "Best" so that the thread is marked as resolved.

Jan

Sign up

Login with SSO here:

Login to the community

Login with SSO here: