Bugs in USB OTG library

[niko]

Posted on January 06, 2010 at 12:10

Bugs in USB OTG library

#usb-stm32

[Nickname12657_O]

Posted on May 17, 2011 at 13:30

Hi all,

We have released a new version 3.1.1

http://www.st.com/stonline/products/support/micro/files/um0424.zip

Refer to release Notes for full details of the changes and fixes. Cheers, STOne-32.

[dan239955_stm1_stmicro_com]

Posted on May 17, 2011 at 13:30

Hi, Niko.

Are you saying that ISOCH IN traffic -- in device mode -- cannot be done with the current library release (3.1.1) for the STM32 CL devices (e.g., STM32F105), without making a lot of changes to the library code?  Is that correct? If so, STone, can you please confirm and advise as to whether a fix is on the way? -Dan

[niko2]

Posted on May 17, 2011 at 13:30

ST USB OTG library has a lot of code copied from Linux USB driver for same (or similar) usb core device.  Linux code is under GPL, and is provided by Synopsys, Inc. The current ST implementation may violate it if the author of the Linux driver is not same organization than ST code (MCD Application Team is marked as author). This is very confusing, since come parts of the code are almost exact copy of GPL'd code. What kind of license is the ST code using?

The USB OTG code is very confusing since headers define a lot of bits and registers that are not available in stm32 CL MCUs (marked as reserved in datasheet). The driver accesses these bits during setup, which indicates it is a sloppily done port of driver for some other platform. Also most fields and registers have completely diffent names than data sheet which makes reading the code very diffult and slow. The current implentation will not be able to do ISOCHRONOUS IN traffic. There are several places in code that do not perform things datasheet defines neccessary for isochronous EPs need to do in order to function. I'm 100% certain nobody has tested ISOCHRONOUS IN traffic with STM32 OUSB OTG driver as it is impossible. ST has not acknowledged this fact. I'm not sure if they even are aware of this since they have answered my (or other developpers) question on this matter with silence. Yes library 3.1.1 was release but it basically fixes bugs that were pointed out in this thread. Nothing else, check the diff yourselves. ST should at least add statement in documentation that tells that ISOCRONOUS IN traffic is not possible with this library and anybody needing it should either use third party library or use ATMEL or some other MCU that has working implementation of USB stack instead of wasting a lot of effort fixing code that does not work. The driver can be modified (with considerable amount of work) to perform ISOCHRONOUS IN traffic. I've done it, but I cannot give you the code as my employer owns the rights to it. So at least rumours about the USB core ST is using in STM32 CL core not being able to do ISOCHRONOUS IN are false.

[niko2]

Posted on May 17, 2011 at 13:30

Yes, I'm not the only one who has been having problems with isochronous in traffic. The USB OTG libarary ST (or Synopsis) provides does not function correctly according to datasheet.

Maybe I'm completely mistaken (wouldn't be the first time, ask my wife) and there is a way to get isochronous in traffic to function with the library but ST has not shown how to do it even example code has been requested on this forum several times.

[dan239955_stm1_stmicro_com]

Posted on May 17, 2011 at 13:30

STOne, can you comment on this?  We have STM32F105 designs in development that will be DOA without the ability to do isochronous in pipes.

Please advise.  If necessary, we will sign an NDA regarding this issue, if that will help us to get confirmation on this and a date when a fix will be available. Thank you! -Dan

[i4reiforever]

Posted on May 17, 2011 at 13:30

From: fu.wei

Posted: Sunday, April 25, 2010 2:38 PMSubject: Bugs in USB OTG library

Hello niko.

Currently I'm writing usb host code for the 107 board,and now I meet the same problem with you.I'm a student and don't have experience on this work. The OTG Lib's code is terrible and I find the initialize code does not at all,with them I could not even detecte the usb device and do enumerate or data trans. I know you could not open your source code,I just want to know how you did the initialize job. Before the OTG core's init,does I just need to enable the RCC for OTG? Did you just follow the RM0008,chapter 26.15.2 's operate and didnt't use the OTG Lib's init func? If not,is there any extra operate that ST just not tell us? Should I just ignore the undefined bits in the OTG Lib? Maybe these questions are silly,but I just have no idea about this : (

[i4reiforever]

Posted on May 17, 2011 at 13:30

modified

[Nickname12657_O]

Posted on May 17, 2011 at 13:30

Hi,

Isochronous IN support will come with the planned Version 3.2.0, Here is attached a patch to apply to two Functions inside the library. Cheers, STOne-32.

[dan239955_stm1_stmicro_com]

Posted on May 17, 2011 at 13:30

STOne,

Thanks very much.  Will give it a try. Niko, Are these the changes you were referring to?  Or are you aware of other issues as well? Thanks, -Dan

[niko2]

Posted on May 17, 2011 at 13:30

>Are these the changes you were referring to?  Or are you aware of other issues as well?

The library still does not work completely according to specifications in STM32F10x reference guide but if the source comes from the chip manufacturer and they say it works then they propably know what they're doing. edit: USB_SIL_Write will work, I read the code too hastily the first time. Sorry.