Bugs in USB OTG library

[niko]

Posted on January 06, 2010 at 12:10

Bugs in USB OTG library

#usb-stm32

[niko]

Posted on May 17, 2011 at 13:30

The USB OTG library that is available in st.com -site has bugs that make it unusable in systems that initialize stack memory to values other than 0x00. Interrupt mask is written using bit-field in uninitialized local variable, which will cause the USB OTG device to start signalling interrupts that are not cleared by the drive code. There are also some other places where bit-fields are set in an uninitialized variables.

I'm not sure why the USB OTG does register IO totally different way from all the other ST-libraries. Storing register addresses in variables and using bitfields is in my opinion inefficient, will generate large code and very it is also sometimes confusing as bitfields don't always have the same as the fields in reference manual. [ This message was edited by: niko.haatainen on 19-11-2009 12:08 ] [ This message was edited by: niko.haatainen on 19-11-2009 12:09 ]

[armmcu]

Posted on May 17, 2011 at 13:30

Hey STone,

could you please comment? cheers.

[benderb]

Posted on May 17, 2011 at 13:30

Niko,

would you share the bug you found? I discovered one such location today, but you hint at more such issues... Thanks Bernhard PS The one I found is here: otgd_fs_int.c: OTGD_FS_Handle_RxStatusQueueLevel_ISR() /* Disable the Rx Status Queue Level interrupt */ + int_mask.d32 = 0; int_mask.b.rxstsqlvl = 1;

[benderb]

Posted on May 17, 2011 at 13:30

Niko,

would you share the bug you found? I discovered one such location today, but you hint at more such issues... Thanks Bernhard PS The one I found is here: otgd_fs_int.c: OTGD_FS_Handle_RxStatusQueueLevel_ISR() /* Disable the Rx Status Queue Level interrupt */ + int_mask.d32 = 0; int_mask.b.rxstsqlvl = 1;

[mcmordie]

Posted on May 17, 2011 at 13:30

P.S. Some issues with the new forums as well.

[mcmordie]

Posted on May 17, 2011 at 13:30

I've discovered that the basic ST USB Custom HID demo (direct from the website) does not work if you shorten the magic number delay in the main loop to a reasonable level.  It even continues to fail when you use end of transfer calls to ensure you are not overflowing the FIFO.  Looks like the OTG USB stack gets into a state when interrupts are not being cleared and the handler goes around in circles... The uninitialized variable issue you mention may be part of the issue.  However, searching through the code for ''.b.'' and reviewing that all bit field assignments occurred on initialized variables does not fix the issue.

I also found the following, which looks like a method of clearing interrupts had been removed and not replaced (and I have no idea as yet how to fix this).  There are several examples with the same comment throughout the OTG stack code.

  /* Clear interrupt: this is a read only bit, it cannot be cleared by register

     access */

  /* int_sts.d32 = 0;

     int_sts.b.rxstsqlvl = 1;      WRITE_REG32 (&core_regs.common_regs->int_sts, int_sts.d32);   */

Without wishing to ruffle any feathers, I have to say that the condition of the OTG library and the total lack of documentation are appalling.  USB support is critical to many of the projects the connectivity line targets, yet it looks like these devices were released without a working USB stack.  Please, by all means, correct me if there is evidence that the stack really does work.

Can ST provide a timetable for release of a fully-tested and working OTG stack?

Does anyone have a working version of the OTG stack which can handle sending data back and forth at a reasonable rate (say 10 ms polling, one endpoint in each direction)?

How many projects out there are on hold because of this?

[daviddavid940]

Posted on May 17, 2011 at 13:30

I got caught with this one too.

I have a tech-support query open with Prague on this one. Actually if you turn on -O3 optimization, the warnings show up the bugs (use before set).

[daviddavid940]

Posted on May 17, 2011 at 13:30

I got caught with this one too.

I have a tech-support query open with Prague on this one. Actually if you turn on -O3 optimization, the warnings show up the bugs (use before set).

[niko2]

Posted on May 17, 2011 at 13:30

I'm having problems with IN enpoints. I've been studying the code in function OTGD_FS_Handle_InEP_ISR and there's a bit confusing piece of code around line 531 in otgd_fs_int.c

...

 else

        {           OTG_DEV_SetEPTxStatus(EP1_IN, DEV_EP_TX_NAK);

          (*pEpInt_IN[epnum -1])();

... Shouldn't it read OTG_DEV_SetEPTxStatus(epnum, DEV_EP_TX_NAK); instead of EP1_IN? Anyways I'm not able to receive anything from isochronous EP2 IN  and I remember somebody else posting about this as well. Could STOne-32 or somebody else involved in developent of ST libraries please comment on this, since it seems that every time there is a bug reported ST replies with deep silence.