cancel
Showing results for 
Search instead for 
Did you mean: 

I have a problem with USB working properly - USB CDC (Virtual Com Port) with CubeMX HAL after disconnecting the USB cable and connecting again.

PMial.2454
Associate II

Hello

I have a problem with USB working properly - USB CDC (Virtual Com Port) with CubeMX HAL after disconnecting the USB cable and connecting again.

For the test I created a project similar to the one presented here - https://www.youtube.com/watch?v=AYICE0gU-Sg using STM32CubeIDE and STM32CubeMX.

The program writes data in the while (1) loop to the USB port after uploading to STM32.

  while (1)
  {
    /* USER CODE END WHILE */
 
    /* USER CODE BEGIN 3 */
    CDC_Transmit_FS(buffer, sizeof(buffer));
    HAL_Delay(1000);
  }

The data is written out, visible in Windows 7 (Tera Term, Docklight).

When I disconnect the USB cable (OTG FS port) and reconnect, Windows sends the message "USB device not recognized".

Data is not received.

In order for the data to be transferred and the cable to be recognized, I must do a Reset on the STM3240G-EVAL board.

Hardware:

STM3240G-EVAL board

Software:

STM32CubeIDE v1.10

Firmware package: STM32CubeFW_F4 v1.24.1

How to make the USB device work all the time correctly (after disconnecting the cable and reconnecting it), so that it is recognized by Windows and data is transferred?

3 REPLIES 3
Pavel A.
Evangelist III

> The data is written out, visible in Windows 7 (Tera Term, Docklight).

> When I disconnect the USB cable (OTG FS port) and reconnect, Windows sends the message "USB device not recognized".

When the device is re-connected, something breaks successful enumeration. Try to understand where it breaks.

Enable debug prints in the USB layers. If you can get a USB analyzer, would be very helpful.

Increase the stack size, if memory allows.

-- pa

SKrau
Associate II

Hi did you found a solution to this problem running in the same thing at the moment

DGvoz.1
Associate

Hello all,

I encountered exactly the same issue.

My setup: custom board with STM32F105RB, USB used as CDC device only meant to exchange messages with host PC.

IDE: STM32cubeIDE 1.5.1, STMcubeMX 6.1.1.

Configuration in STMcubeMX:

USB DEVICE: Class CDC, all other settings with defaults.

USB_OTG_FS: Mode Device Only, all other settings with defaults.

After many hours spent debugging i found strange behavior in below IF block inside stm32f1xx_hal_pcd.c file.

If i put a breakpoint before the IF, when the USB cable is disconected, the breakpoint is hit. When the execution is continued after the breakpoint the IF is skipped because the condition inside IF is false.

But if that breakpoint is removed and another one is placed in the line with HAL_PCD_SuspendCallback(hpcd), that breakpoint gets hit although with the previous breakpoint it was never executed because the IF condition was not met. It seems something is polluting the variables used in IF statement, which doesn't happen in case of breakpoint above the IF statement.

In case HAL_PCD_SuspendCallback(hpcd) is not executed the USB cable disconnect is handled ok, and upon USB cable reconnection the USB device is recognized by PC. It seems that call to HAL_PCD_SuspendCallback(hpcd) is causing this issue.

So my solution was to just comment out that part of the code containing the IF statement and HAL_PCD_SuspendCallback(hpcd) .

After that, connecting and disconnecting work as expected, as well as the data transfer between my STM32 board and the PC.

Hopefully somebody will come up with a proper explanation of such behavior.

In stm32f1xx_hal_pcd.c i have commented the following bold part of the code:

  /* Handle Suspend Interrupt */

  if (__HAL_PCD_GET_FLAG(hpcd, USB_OTG_GINTSTS_USBSUSP))

  {

//   if ((USBx_DEVICE->DSTS & USB_OTG_DSTS_SUSPSTS) == USB_OTG_DSTS_SUSPSTS)

//   {

//#if (USE_HAL_PCD_REGISTER_CALLBACKS == 1U)

//    hpcd->SuspendCallback(hpcd);

//#else

//    HAL_PCD_SuspendCallback(hpcd);

//#endif /* USE_HAL_PCD_REGISTER_CALLBACKS */

//   }

   __HAL_PCD_CLEAR_FLAG(hpcd, USB_OTG_GINTSTS_USBSUSP);

  }

0693W000007EcWGQA0.png