Problem with USB Host CDC class

mailforspam · ‎2014-07-03

Posted on July 03, 2014 at 12:01

Hello,

I'm using STM32CubeMX to generate a project for STM32F207 that uses USB Host. The project compiles without problems. I have a custom USB device that uses CDC to send and receive serial data. When the device is attached to the USB host, it is detected correctly and the CDC class is being started. The functions for writing to and reading from the USB device are USBH_CDC_Transmit and USBH_CDC_Receive. These functions are non-blocking, and there are 2 callback functions that are called when the data have been transferred - USBH_CDC_TransmitCallback and USBH_CDC_ReceiveCallback. I have made some tests reading and writing the device and discovered, that I have to wait the last operation to finish before calling again the functions for reading or writing. The problem is that if I call USBH_CDC_Receive and the device is not sending anything at the moment, I cannot use the USB device anymore, I can call USBH_CDC_Transmit or USBH_CDC_Receive as much as I want, they won't block, but they just won't work. The detaching and attaching again of the device won't be detected by the USB Host Library. How can I find a workaround of that issue? I want to be able to read the USB device, but I don't know how much data I'm expecting, otherwise I would stop calling USBH_CDC_Receive.

#stm32cubemx #cdc #usb-host

Taylor.Sean · ‎2014-11-11

Posted on November 11, 2014 at 17:31

I think I am having the same problem. Did you find a solution ?

Taylor.Sean · ‎2014-11-12

Posted on November 12, 2014 at 17:53

I have narrowed the problem down to the USB CDC transmit being unreliable. I put a log breakpoint on

HAL_StatusTypeDef USB_WritePacket(USB_OTG_GlobalTypeDef *USBx, uint8_t *src, uint8_t ch_ep_num, uint16_t len, uint8_t dma)

Which is always called with dma=0: each time USBH_CDC_Transmit() is called followed by USBH_Process() I see data passed to this function with the correct parameters: the only problem is that this doesn't guarantee that the USB data will appear on the bus: sometimes it does and sometimes it doesn't.

USBH_CDC_Receive() is working reliably, but I'm at a loss for now why USBH_CDC_Transmit() is so unreliable. If I don't make progress in the near future I'm going to ditch the STM and go back to the NXP LPC on which USB CDC (using LUFA) works fine.

mailforspam · ‎2014-11-13

Posted on November 13, 2014 at 11:35

After a large number of trial and errors, I changed the System Clock Configuration and now the USB is working. I changed AHBCLKDivider from 1 to 4 and HCLK is 30MHz instead of 120MHz. The STM microcontroller is 4 time slower now, but I couldn't find another solution. I have no idea how to make the USB working without reducing the clock frequency.

Taylor.Sean · ‎2014-11-13

Posted on November 13, 2014 at 17:30

Thanks for taking the time to reply. I'm finding similarly: if I sprinkle delays around the code (I'm using multiple milli-seconds since 1ms is my Systick) I can kind of get USB to limp along.

There seems to be some sort of guard period required between consecutive calls to USBH_CDC_Transmit(), USBH_CDC_Receive() and USBH_Process(). Tracing has shown that transmit and receive requests always get passed correctly to the HAL and USB driver level, but

- If called without delays the USB transmit occasionally (often) just fails to put the data on the bus.

- If called without delays the USB receive functions occasionally (often) just fail to return received data that I can clearly see on my USB analyzer is being received.

I conclude that the STMCube Host USB drivers have a serious problem that ST needs to address.

I will try lowering the clock rate, but it's an unsatisfactory long term solution.

leiming · ‎2014-11-14

Posted on November 15, 2014 at 08:28

I met the same problem with CubeF4 on STM32F407.

As mentioned above, USBH_CDC_Transmit sometimes can not send data out. In my tests, it seemed that this problem will cause data queued in txfifo, and later USBH_CDC_Transmit calls will send previous data out.

I have not tried to slow down the frequecy.

Hope ST can recognize and resolve this problem as soon as possible.

leiming · ‎2014-11-15

Posted on November 15, 2014 at 10:21

As user.st said, I tried to slow down AHB freq from DIV1 to DIV4 (42MHz in stm32f407), and the problem is resolved, both transmitting and receiving are working fine now.

I believe this problem is a problem of hardware or low layer drivers of USB host, it should not be a problem of CDC class. But I'm wondering why all of us met this problem in CDC host application, not in other applications. Other USB host applications (e.g. MSC class, which also uses BULK transfer) can work fine (without frequency slowing down)?

bluexav · ‎2014-12-12

Posted on December 12, 2014 at 18:01

Hello ! I have a similar problem here especially when device disconnection/reconnection is never detected in my project. Slowing down the board did not work for me.

Dis you find a solution ?

Thanks.

Montassar BEN ROMDHANE_O · ‎2015-02-16

Posted on February 16, 2015 at 18:15

Dear user,

Are you using the USB host CDC example ''as is'' or did you modify it ?

In case you modified the example, is it possible to send us the code?

What is used as USB device CDC ? Is it an STM32 or an FTDI USB to UART converter ?

Best regards,

Heisenberg.

kqian · ‎2015-03-11

Posted on March 11, 2015 at 22:00

Anyone figure out how to fix this problem?? Could you please share the solution if you did.