• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 577 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

RTOS/PROCESSOR-SDK-OMAPL138: possible race condition in PDK 1.0.5 bulk usb device driver

RTOS/PROCESSOR-SDK-OMAPL138: PDK 1.0.5 USB bulk device

Adam Wozniak66
Intellectual 920 points
Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: OMAPL138, OMAP-L138

Tool/software: TI-RTOS

In pdk_omapl138_1_0_5/packages/ti/drv/usb/src/usb_func/device/usb_dev_dman.c I see

/** \brief Global variable to contain the request which is to be made to
 *         the lower layer driver.
 */
usbDevRequest_t req;

Which pretty much means there can only be one request "in flight" at a time.

I'm using the USB bulk device, and I'd like to be doing reads in one task while doing writes in another task, because I'll be constantly producing data, and host writes will be only occasional.

It seems this global request variable will be clobbered by the two tasks.

Is my design goal reasonable?  (i.e. would the hardware support it if the driver were written properly?)

Or do I just not understand how USB Bulk devices are supposed to work?

  • 0
    TI__Mastermind 27355 points
    Hi Adam,

    Just want to let you know I'm looking into this with our USB expert. I will keep you posted.
  • 0 in reply to Sahin Okur
    TI__Guru* 95265 points
    Hi,

    I found this: docs.microsoft.com/.../usb-bulk-and-interrupt-transfer

    Here are the key features of a bulk endpoint:
    ....
    The endpoint is a unidirectional and data can be transferred either in an IN or OUT direction. Bulk IN endpoint is used to read data from the device to the host and bulk OUT endpoint is used to send data from the host to the device.

    So, I don't think you can do bulk in duplex (one task for read and the other for write, running in parallel). We also have bulk examples in Processor SDK RTOS for Sitara AM3x, 4x, 5x devices. The example code under pdk_am335x_1_0_x\packages\ti\drv\usb\example\usb_dev\bulk. There is only one task. The host writes to bulk device first, then the device responses back.

    This should be the same for OMAP-L138 device.

    Regards, Eric
  • 0 in reply to lding
    Intellectual 920 points

    I don't think my question came across well.

    You are correct that an individual *endpoint* is unidirectional.

    My question is about a device with *TWO* USB endpoints, one IN_EP and one OUT_EP, as in the PDK 1.0.5 USB Bulk Device example.

    In the PDK, both USBD_bulkRead and USBD_bulkWrite are blocking operations

    If you try to do a USBD_bulkRead, you will block forever, until the HOST sends something.

    If the host then tries to read something, it will get nothing, because you can't USBD_bulkWrite on the other endpoint, because you're still blocked inside USBD_bulkRead for your first endpoint.

    Now I wanted to decouple this, so I thought I could just do USBD_bulkRead in one task and USBD_bulkWrite in another.  This is desirable because I do not know the timing or order of reads/writes a-priori.

    It seems like this should be possible if the drivers are well written; when you get a USB interrupt for an endpoint, you dispatch it based whatever is going on for that endpoint.  Operations on one endpoint should NOT affect operations on other endpoints.

    Digging down into usbdbulk.c, you can see both the USBD_bulkRead and USBD_bulkWrite call usbSetupEpReq(), which fills in this GLOBAL usbDevRequest_t req (which I assume gets picked up by a dispatcher of some sort).  *ugh*.  This seems like a glaring design flaw.  This should be a queue of request objects, so multiple Tasks can queue up transactions on different endpoints and not clobber each other.

  • 0 in reply to Adam Wozniak66
    TI__Guru* 95265 points
    Hi,

    I checked with the USB driver development team: USB communications are host driven. The USB host tells the USB device when to send or when to read. The device cannot send data to the host without the host asking for data first.

    We implement the USB bulk similar to the way to the USB MSC implementation. Host sends a command to the device (whether it is a read / write command) then the device writes or reads from the host depends on what the previous command is. The bulk device example is thus implemented exactly that. It waits for data from host then sends back to data to the host.

    I don’t know how customer application work or what he really wants to do so I cannot give any recommendation. But in general the device cannot send data (using bulk_write) to host without the host asking the device to send first. The device cannot know when the host wants the device to send data until it has received something from the host.

    That’s my thought. Hope it makes sense

    Regards, Eric