libusb + STM32F4 + USB3300, how to clear last residual data

[FDou]

ibusb + stm32f4 + usb3300

Software crush when ARM is communicating with PC. The PC will receive the last residual data, after restart the software.

How to clear the residual data, in the software or firmware?

[Bob S]

Is the F4 configured as USB CDC? If so, my guess is that the data is probably buffered on the PC side, waiting for some lower-level CDC protocol event. Specifically, if you are sending lots of data, CDC will send it in 64-byte packets and the "end of data" signal is either a packet with less than 64 bytes, or a zero length packet (which I guess qualifies as "less than 64 bytes" 🙂

I can't think of a way the data could be left on the F4 side of things and survive a reboot/restart. However, restarting the F4 firmware will cause it to disconnect from the USB, then re-connect and re-enumerate. That disconnect closes the PC's serial port handle and flushes any remaining data.

You can verify this by causing the crash again, then before restarting the F4, unplug the USB cable and see if the PC sees the residual data.

Of course, the REAL answer is to not crash the ARM 🙂

[FDou]

Yes, F4 configured as USB CDC. The F4 send data to PC using DCD_EP_Tx(&USB_OTG_dev,CDC_IN_EP,SendDataBuff,15)

I want to make sure you don't misunderstand, After the PC software crash not F4 crash, the PC software will receive the last residual data, after not reboot F4 but only restart the PC software.

I tried your suggestion, unplug the USB cable after crash the PC software, then the PC software cann't find the USB device.

This may be related to the USBD_Init only execute as below.

int main(void)

{

  USBD_Init(&USB_OTG_dev,

     #ifdef USE_USB_OTG_HS

       USB_OTG_HS_CORE_ID,

     #else

       USB_OTG_FS_CORE_ID,

     #endif

       &USR_desc,

       &USBD_CDC_cb,

       &USR_cb);

  while(DeviceConfigured==0);

  while(1)

  {

}

}

[Bob S]

Sorry, I misunderstood. If the PC side crashes, **IF** you are going to unplug the USB, you also need to re-plug it before you re-start the PC software. At which point the PC software **SHOULD** be able to open the COMxx port again. Is that what you did? But that is just a kludge work-around. Is your board USB powered, or does it have an external power supply? If it uses an external power supply, I'm not sure the default HAL code properly handles the USB being unplugged and re-connected/re-enumerated. I'm not sure because I've never (yet) used the HAL USB CDC implementation, I've only used the F4 STL version, and I think I had to add code to handle disconnect/reconnect events.

I'm not sure if the data is buffered on the PC side, or still in the STM32 side. The easiest way to deal with this is to have the PC software open the COM port, then read data (and throw it away) until there is no more data to read. Of course, this presumes that your STM32 firmware is designed to send data only after being told to send it. If instead the STM32 powers up, waits for USB connection then just starts sending data..... well, it gets more difficult, and you need to look at how that data is structured to see if there is a way to separate "old" from "new" data.

There were some discussions a while ago about trying to have the STM32 detect when the virtual COM port is opened or closed. You can try searching for those threads. *IF* you can detect when the VCOM port closes, you can have the STM32 clear any data that is queued for sending. But that still leaves the possibility of data buffered in the PC (again, I don't know if this can happen or not).