Unplug USB from stm32f205 during data exchange

Vyacheslav Popov · ‎2017-01-18

Posted on January 18, 2017 at 12:53

Hello there.

I have problem with USB Device CDC based MX Cube for stm32f205.

When custom program exchange data with device I unplug USB. Then after some time I connect cable again.

I can see that device send data from previous transfer (which was not sent in last transaction because I unplug USB) instead I send using CDC_Transmit_FS.

Next behaviour looks like as FIFO. For example:

1) I send 0x00 0x01 0x02 but receive old data (which device send at moment I unplug USB)

2) I send 0x03 0x04 0x05 but receive 0x00 0x01 0x02

3) I send 0x06 0x07 0x08 but receive 0x03 0x04 0x05

Before call CDC_Transmit_FS I write in console what data I send. So I sure that correct data should be sent.

If I manually call USBD_DeInit and MX_USB_DEVICE_Init after then data start send in valid sequence.

What is the problem?

Also I`ll try to handle this case in HAL_PCD_DisconnectCallback but when I unplug USB it is no called. Instead this calls HAL_PCD_SuspendCallback.

What I need to do for fix it.

Vyacheslav Popov · ‎2017-01-19

Posted on January 19, 2017 at 09:24

Disconnect callback should called from USB interrupt when SEDET bit is set. But when I disconnect cable the bit is not set. I measure PA9 and saw that their level is not zero but about 2 volt. If I connect this pin to ground disconnection callback is called. Internal GPIO pull up do not help. This pin connect only to VBUS.

I set 4.7K resistor beetween VBUS and GND and now disconnect callback work.

How to make it work without external pulldown resistor?

Imen.D · ‎2017-01-19

Posted on January 19, 2017 at 11:58

Hello @

Popov.Slava

,

You may refer to the

http://www.st.com/content/ccc/resource/technical/document/reference_manual/51/f7/f3/06/cd/b6/46/ec/CD002257pdf/files/CD002257pdf/jcr:content/translations/en.CD002257pdf

and

http://www.st.com/content/ccc/resource/technical/document/reference_manual/51/f7/f3/06/cd/b6/46/ec/CD002257pdf/files/CD002257pdf/jcr:content/translations/en.CD002257pdf

as mentioned that for STM32F205 devices there is no need to add any external resistors for USB as featureHNP/SNP/IP inside.

Regards

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

Vyacheslav Popov · ‎2017-01-19

Posted on January 19, 2017 at 13:30

Thank you for response.

I know that resistors is no need. But what is the 2 volts which I measure in VBUS when cable is disconnected?

Non zero voltage in VBUS is reason why disconnect callback is not called.

And what about my first question? USB work properly only if I deinit and init it again (after disconnect during data exchange)

Vyacheslav Popov · ‎2017-01-19

Posted on January 19, 2017 at 14:41

I add some code toHAL_PCD_DisconnectCallback (lines 4 and 5):

void HAL_PCD_DisconnectCallback(PCD_HandleTypeDef *hpcd)
{
 USBD_LL_DevDisconnected(hpcd->pData);
 USB_FlushTxFifo(hpcd->Instance , 0x10);
 USB_FlushRxFifo(hpcd->Instance);
}
�?�?�?�?�?�?

Now receive sequence is valid.

Is it right way to call this flush functions in ISR?

tsuneo · ‎2017-01-19

Posted on January 19, 2017 at 18:47

Vyacheslav Popov wrote:

But what is the 2 volts which I measure in VBUS when cable is disconnected?

Non zero voltage in VBUS is reason why disconnect callback is not called.

Maybe your board mount a wrong protection diodes.

I had posted on this issue in this topic

Detecting disconnection (unplug) on USB device

B) Wrong choice of protection diodes on USB lines

If your board would mount protection diodes for D+/D- line with high-side diode, like USBLC6-2, the diode keeps VBUS voltage, passed by the D+ pull-up resister, after plug off. And then, VBUS drop isn't detected.

In above post, you'll see comprehensive diagram on this issue 😉

Tsuneo

Sarv Parteek Singh · ‎2017-03-09

Posted on March 10, 2017 at 02:44

I had a similar problem and based on a lot of experimentation and feedback from ST's experts this is what I found:

You can have this problem if the device is not getting disconnected but the host is. USB connect/disconnect on device is ascertained by examining the VBUS line. When you unplug your cable from the port, you will lose comms (over D+ and D-) lines first and then lose VBUS (this might be because contact with the USB shield will allow the device to detect VBUS but you have to plunge the USB into the port a bit before the device can sense D+/D-). If you do not unplug your cable all the way out, it is possible that the device thinks that there has been no disconnection (because VBUS is still alive) but since D+/D- have lost connection, the host thinks that it has lost the device.

You can verify this by turning on/off an LED in HAL_PCD_DisconnectCallback() and HAL_PCD_ConnectCallback() in usbd_conf.c. If this is indeed the case, then that means that your VBUS stays high when you do a disconnect/connect sequence. So, while your STM32 device will not see a disconnection, USB will go into a suspend state because of no activity on the D+/D- line. When USB cable is plugged back in, the host will force a re-enumeration on the device. You can confirm this by looking at the HAL_PCD_ResetCallback() in usbd_conf.c

If you can ensure that HAL_PCD_ResetCallback() is called upon a re-connection (by placing a breakpoint/LED), then all you need to do is the following:

void HAL_PCD_ResetCallback(PCD_HandleTypeDef *hpcd)

{

USBD_SpeedTypeDef speed = USBD_SPEED_FULL;

/*Set USB Current Speed*/

... // do not change the default code here

...

USBD_LL_SetSpeed(hpcd->pData, speed);

/*Reset Device*/

USBD_LL_Reset(hpcd->pData);

USB_FlushTxFifo(hpcd->Instance,0x10U); // new line to clear all Tx FIFOs. ADD THIS LINE

}

The USB_FlushTxFifo() call will reset your transmission buffers and your problem should get resolved.

Note that I had this problem on an STM32F4 device. Also, I had Vbus sensing Enabled on my device.