USB Host stack is not stable during CDC communication

lukasz23 · ‎2015-02-04

Posted on February 04, 2015 at 21:20

Currently we are working with STM32F217 MCU and we use USB Host in FS mode to communicate with some external device. We use CDC class driver generated by STM32Cube plug-in to Eclipse. We are facing some problems with communication over USB. After some send/receive sequences USBH_CDC_TransmitCallback() is never called again. CPU clock is 120MHz. This problem has been noticed by other user in following topic:

/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Problem%20with%20USB%20Host%20CDC%20class&%3bFolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&%3bcurrentviews=289

Because callback is never called after some sends we are not able to implement proper communication using it. It seems when CPU clock is below 30MHz it is more stable, but this is not solution/option for our project, because we need to run CPU at the highest frequency because we are planning to transfer a lot of data through the USB interface.

Our current analysis:

1) After 1 or 2 send sequences USBH_CDC_TransmitCallback() is never called.

2) USBH_CDC_TransmitCallback() is not called because in CDC_ProcessTransmission() URB_Status always equals USBH_URB_IDLE.

3) URB_Status does not change from USB_URB_IDLE to USBH_URB_DONE because interrupt for out pipe (function HCD_HC_OUT_IRQHandler() ) is not called (it is called at the beginning and it stops after 1 or 2 send sequences).

4) Interrupts for in pipe seems to be handled properly (ISR function for RCV is called periodicaly).

5) After each USBH_CDC_Transmit() proper data are placed in TX_FIFO of USB peripheral - USB_WritePacket function is called with proper parameters.

I'm looking forward for some help with this problem.

null

rabryan · ‎2015-02-12

Posted on February 12, 2015 at 16:45

We struggled with this exact same problem as well. We ended up implementing a timeout for the TransmitCallback. If it doesn't get called after 50ms, we flush the tx buffer and retransmit.

We only implemented this for bulk data though. We're seeing a similar thing now with control setup transactions (the XFRC interrupt never gets triggered and URB state stays in IDLE forever) so we're looking into implementing the same thing with that.

In general, we've found so many bugs with STM's USB modules and their lack of support or response is insulting. Never going to use an ST chip again...

Montassar BEN ROMDHANE_O · ‎2015-02-16

Posted on February 16, 2015 at 17:14

Hi baj.lukasz,

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.

lukasz23 · ‎2015-02-17

Posted on February 17, 2015 at 12:35

Thank you for your response.

We have modified it to support second USB CDC class device. Anyway we saw this problems also without our modifications and with CDC example provided by ST.

We have modem connected to USB FS Host. Modem is based on Gemalto EHS6 module.

http://m2m.gemalto.com/products/industrial/lga/ehs6.html

We use CDC class to communicate with it, send some AT commands and then transfer PPP packets back and forth.

I have to confirm how we can share code with you. As I understand correctly you need USB Host code which we use in our project, right?

Lukasz

Montassar BEN ROMDHANE_O · ‎2015-02-18

Posted on February 18, 2015 at 15:05

Hi Lukasz

We'll try to reproduce the same behaviour with other devices and to figure out where a problem could be.

Best regards,

Heisenberg.

lukasz23 · ‎2015-02-26

Posted on February 26, 2015 at 11:26

@Heinsenberg: any progress with investigation? Are you able to reproduce the issue?

lukasz23 · ‎2015-03-01

Posted on March 01, 2015 at 21:10

Hi Heinsenberg,

We have done some more investigation on USB issue and I have some more info which could be valueable for you to find root of the problem:

- Data put in TX_FIFO are never sent through interface so after each write to thisFIFO available space is decremented till it reaches zero

- TX_FIFO is blocked if NPTQXSAV bits in OTG_FS_HNPTXSTS register equals zero(refer to 29.6.4 Host scheduler chapter in UM). This means that sometimes tomany USB requests are placed in scheduler

- Library (STM32 USB host driver) code does not protect against behavior described above. Nevertheless currentlywe do not know why NPTQXSAV reaches zero. This zero value is reached rapidly(8->7->6->0) but there is no 8 requests placed in scheduler. We haveadded some protection (no new request put if NPTQXSAV == 0) in HAL layer but itdoes not help

Lukasz

Montassar BEN ROMDHANE_O · ‎2015-03-04

Posted on March 04, 2015 at 11:42

Hi baj.lukasz,

Thank you for the information, could you provide the USB trace ?

_Heisenberg_