Bugs in USB OTG library

[niko]

Posted on January 06, 2010 at 12:10

Bugs in USB OTG library

#usb-stm32

[Nickname13100_O]

Posted on May 17, 2011 at 13:30

The isochronous in traffic works with these modifications and theyre actually bit simpler than the ones I made, I used fifo empty interrupts to fill tx-fifos for eps (as the library does for other in endpoints).

There is however still a flaw in the library. Current library sets the odd/even bit in endpoint register based on the frame number of last frame that was received assuming the in endpoint must send data in next frame. This is not neccessarily true since host may request data from an in ep at lower rates than once in every frame. It might be wise to change the code so that the odd/even bit is set based on even_odd_frame flag in endpoint structure allowing the user to determine the state in which the bit needs to be.

[chikos332]

Posted on May 17, 2011 at 13:30

Hi,

I'd like to understand something in your solution please:

If you disable the TxEmptyFifo interrupt after each write, how you will write again to the FIFO next time? When you do the next write you are not sure that the FIFO is empty ...

Now, if you are transferring small amounts of data at large periods of time, then it would be OK... bu if you need fast and large data packets, then I  think you may have a lot of troubles.

There may be one other solution, but I haven't test it yet (I didn't encounter a similar issue till now): You could reduce the FIFO size for this endpoint to be exactly the number of data you transfer at each frame... maybe this way the TxFIFOEmpty interrupt will not rise till the end of the current transfer..

Did someone try similar solution ?

[german]

Posted on May 17, 2011 at 13:30

Hi!

I've found a problem with the last USB OTG library ( V 3.1.1 ). When the code calls the function USB_SIL_Write, after transmiting the last portion of data ( or the only portion if the data size is lower than the EP size ), an interrupt is issued continually due to the empty fifo interrupt event. This interrupt is asserted until the Transfer Complete event is received (read complete from the host side) and the empty fifo mask is cleared. But until that, the STM32 is bloqued from hundreds of micro-seconds to several mili-seconds serving this interrupt ( this time deppends of the host side too, and can be even larger ).

To solve this ( I'm not sure if this is the correct way to solve this issue ) I added the following code in the function  OTGD_FS_PCD_WriteEmptyTxFifo ( line 811 of the file otgd_fs_int.c :(

  if ( len <= 0 )

 

   MODIFY_REG32(&core_regs.dev_regs->dev_fifo_empty_msk, 0x1 << ep->num , 0);    

This two lines disable the empty isr for that ep when there is no more data to transmit.

Sorry for my English!

Cheers!

German Ortiz

[Nickname12657_O]

Posted on May 17, 2011 at 13:30

Hi,

Yes you are absolutely right. This odd/even management be fixed as well.

Cheers,

STOne-32.

[chikos332]

Posted on May 17, 2011 at 13:30

May be this post should become a seperate forum for itself, regarding the number and variety of posts and questions on the subject...

STOne, what do you think ?

[love21cz]

Posted on May 17, 2011 at 13:30

Do you know the schedule for the v3.2.0  release of new USB_OTG libs?

[german]

Posted on May 17, 2011 at 13:30

With this solution, the TxEmptyFifo interrupt is disabled as soon as the transmision is finished, and it is re-enabled when you start a new transmision.

It's true, in my case I'm not transmitting big quantities of data, and i can't confirm this will work in that case, but this solution resolves the issue about entering coninuallly to serve the TxEmptyFifo whith NO DATA to Tx, and losing others ISR with lower prioritys.

[paulm2]

Posted on May 17, 2011 at 13:30

I am using a STM32f105 in a project, connected as a device to a CE terminal. The usb driver in the terminal cannot handle IN and OUT endpoints with effectively the same number, ie 0x03 and 0x83 are seen as the same. I have tried several ways of changing the USB library to achieve different endpoint numbers, ie 0x03 and 0x84, but to no avail. I can use different numbers for IN and OUT if the numbers are less than 3 but this then limits the number of pipes to 1 and there is too much data from 5 serial ports and 2 can ports along with misc data to throw down one pipe. Is it possible to change the endpoint numbering or is it fixed in some way. I suspect it is fixed due to the register layout and fifo's but can anyone confirm this?

[thomasbretgeld9]

Posted on May 17, 2011 at 13:30

I think I found another bug today regarding suspend and resume with CL devices:

Inside the usb_istr.c function STM32_PCD_OTG_ISR_Handler the Suspend() function from usb_pwr.c gets called on suspend, but the corresponding call to Resume(RESUME_STATE) is missing. This leads to an incomplete resume procedure after suspend. This only applies to CL devices.

Inside the STM32_PCD_OTG_ISR_Handler function the following change fixes the issue:

#ifdef INTR_WKUPINTR   

    if (gintr_status.b.wkupintr)

    {

      //Begin Added by Thomas Bretgeld

      Resume(RESUME_EXTERNAL);

      //End Added by Thomas Bretgeld

      retval |= OTGD_FS_Handle_Wakeup_ISR();

    }

#endif /* INTR_WKUPINTR */  

Kind regards,

Thomas Bretgeld

[thomasbretgeld9]

Posted on May 17, 2011 at 13:30

I have also found several bugs in the library:

1. https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fARM%20CortexM3%20STM32%2fBUG%20%28USB_OTG_LIB%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E&currentviews=127

2. The Data toggle bit is not reset correctly after a ''Set Interface'' request, so that in 50% of the cases the first packet may be lost due to an invalid data toggle bit (I already reported this several months ago to ST).

3. Something that I am not 100% sure, if its a library bug, but I couldn't find any problem with my software so far: I am using a STM32F105RBT6, EP1 IN and OUT in Bulk Mode, 64bytes wide. When sending data from the CL device to the host, this works only, if the number of bytes sent are _not_ a multiple of 64bytes. As soon as it is a mulitple of 64bytes, the packet gets lost somehow. Can anybody confirm this? I am using Library V3.2.1.

My current workaround is to add a padding byte in case of sending a multiple of 64bytes. This works, but its not a good solution.

Kind regards,

Thomas