Forums

Is this why?

sprufw6b.pdf section 2.6:

• "The USB controller supports a total of 4K RAM to dynamically allocate FIFO to all endpoints."
• "The Endpoint 0 FIFO has a fixed size (64 bytes)"

Therefore RX(2048) + TX(2048) will be too big? But then why can't I set, say, the IN FIFO to 1024 and the OUT FIFO to 2048? Is there a symmetry requirement?

Are the 2048 and 4096 options vestigial?  (E.g., work for OMAP-L138?) And what does the "biju" comment mean for 8192?

Alternatively, USB in a nutshell: Maximum data payload size for high-speed devices is 1024 bytes. [but isn't packet > payload?]? But then, why are the 2048, 4096, 8192 options even available at all?

Hi Jonathan Chen,

The 4K restriction is true for Dynamic FIFO configurations only.

The StarterWare USB stack supports endpoint FIFOs and have been tested for FIFO size 64.

Are you testing the bulk class application provided with StarterWare?

Can you please let us know the reason for your trying to go for FIFO sizes up to 4k please?

have you made any changes to use DMA in your application?

Regards

Sirish

Dear Sirish,

Yes, I am testing the StarterWare AM1808 usb_dev_bulk example, no changes to DMA in the example or the library code.

Reasons for changing FIFO size:

• curiosity while testing custom host (PC) code, using libusb-1.0
• problems with PC code for a bulk IN transfer that is exactly the FIFO size
  - if I can't fix my PC code, I would at least want to maximize FIFO/packet size
  - see this thread

Newer observations from my testing with usb_dev_bulk, using the same size FIFO for Tx and Rx (this is probably required for loopback?):

• all FIFO sizes from 8-512 seemed to work correctly
• transfer problems were encountered for 1024 + usb_bulk_example.exe (modified to allow 1024 input)
  - host bugs out for transfers greater than 950 bytes and requires hard shutdown to release USB device!
  - smaller transfers still work fine
  - enumeration still works fine
• as before, 2048 and 4096 do not enumerate

Thank you!
Jonathan