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.

CSL USB: Can't retrieve OUT data from the FIFO with USB_postTransaction.

Hi,

It seams as no matter how I setup and call USB_postTransaction in the csl_usb_intc_example. I never get the data in "usbDataBuffer" buffer that I'm sending from the host. In the FIFO i can see some of the data when breaking right after USB_postTransaction (when looking at "pFifoAddr" in the "USB_handleRx" function in the "csl_usbAux.h" file), but I never get anything in the "usbDataBuffer". I get this in the FIFO when I sent 0x1122334455667788 from the host:

 

It looks like I get the "4433" and the "8877" in the FIFO somehow but never gets to the usbDataBuffer (unless I modify "USB_handleRx" function to read from *(pFifoAddr+5) for example, which seams very wrong).

Looking at an older post, it seems like it should be at least be possible to receive data from the OUT point (not considering sending back to the host through IN point): http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/50007/178421.aspx#178421

I know I probably shouldn't use the example since it meant for looping the buffer back to the host, but I just want to make rapid prototyping since I'm only one person working on the platform right now.

Thanks,

Stefan

  • Hi Stefan,

    The CCS memory window capture is not the content of the USB EP FIFO. It is the USB EP FIFO registers. for example, 0x8429 is the  FIFO2R1 Transmit and Receive FIFO Register 1 for Endpoint 2. You can read it word by word to get all the contents in the EP FIFO. That is what the USB_handleRx do. What triggers the USB_handleRx is the      (pContext->dwIntSourceL & CSL_USB_RX_INT_EP2)  in usb_isr() via USB_postTransaction(). To make sure you actually get data waiting in the EP2, you can add the following code before USB_postTransaction() in usb_isr():

       // read the RX packet size
       // validate the RX packet first
       if (USB_isValidDataInFifoOut(&pContext->pEpStatus[CSL_USB_EP2]))
       {
        // get the EP2 handle
        tempEpH = USB_epNumToHandle(CSL_USB0, CSL_USB_EP2);
        usb_income_num_bytes = USB_getDataCountReadFromFifo( tempEpH );
       }    

     to get the data waiting in the EP2 FIFO in terms of bytes.

    After calling USB_postTransaction(), the calling to USB_isTransactionDone() will tell you the status of this operation. If everything is OK, then you should have the data in usbDataBuffer.

    If you did not get what you suppose to get, it could be the USB host program is not doing the right thing. Here are some possibilities:

    1. The host program is sending data in packet size bigger than 64 bytes at a time

    2. the host program is sending data to EPs other than EP2 (EP1 for IN and EP2 for OUT)

    Best regards,

    Ming

  • Hi Ming,

    Thanks a lot! That made sense. After trying out what you suggested I realized that I was using to the wrong end point ("pipe 0x01" in my host program which is obviously EP1). If I sent to "pipe 0x02" instead, it works fine (Makes me feel a bit silly now). Only thing I wonder about now is why CSL_USB_IOFLAG_SWAP doesn't swap the byte order for me.

    Thanks,

    Stefan Gram

  • Hi Stefan,

    I am glad things are working for you now.

    Speaking of the usage of CSL_USB_IOFLAG_SWAP, C5515 USB hardware does not support the byte order swapping. In fact, it is hardwired. Register CONFIGDATA (read only) bit 5 will tell you what is the current endianness of the USB core. The actual byte swap should be done by the software. Unfortunately the CSL USB driver did not process the CSL_USB_IOFLAG_SWAP request. That is why you did not see the difference.

    In C5515, the USB CPU polling mode will give reversed byte order in 16 bit (i.e. 0x12, 0x34 will be received as 0x3412). The USB CPPI DMA mode will give you the correct byte order in 32 bit (i.e. 0x12, 0x34, 0x56, 0x78 will be received as 0x12345678).

    Best regards,

    Ming