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 v2 USB Queue Manager

Other Parts Discussed in Thread: TMS320C5515

 

Hi,

Is there any reference for the Queue Manager that has been implemented in the new v2 CSL?

Only one function is there (USB_initQueueManager) but the whole functionality is not known and how the remaining usb dma functions interact with the queue manager or what flags and interrupts are raised, queue statuses etc

I cannot seem to find anything that describes how this whole CSL v2 USB Queue manager framework operates.

There is of course the generic CPPI/CDMA/Queue manager documentation in sprufo0 but in there is the H/W register explanation and functionality, not how it is implemented via the CSL functions.

 

Thanks for any help.

Christos

 

 

 

  • Hi,

    Can someone please help here.
    I've managed to succesfully exercise the csl_usb examples (dma/int/poll).


    Yet again a problem came forward and that is specifically on the data that is reading the host from IN pipe.

    On all the examples (poll/int/dma), the test procedure is to write (from a windows host) a sequence of bytes to OUT pipe and to supposedly read back that same sequence coming from the IN pipe.

    For our case, we do not want that, we need to have not the same data between OUT and IN, so we proceeded with ammending the example in order to return another reply back to IN pipe.

    We tried to use different buffers
    Uint16    usbDataBuffer[CSL_USB_DATA_SIZE];
    Uint16    usbDataBuffer2[CSL_USB_DATA_SIZE];
    and we populated them with different contents
        for ( i=0; i<CSL_USB_DATA_SIZE; i++ )
        {
            usbDataBuffer[i] = 0x0202;
            usbDataBuffer2[i] = 0x0000;
        }
    and we changed accordingly the references in the dma functions
    USB_confDmaRx(&hpdrx, CSL_USB_EP2_PACKET_SIZE_HS, usbDataBuffer2);
    USB_confDmaTx(&hpdtx, CSL_USB_EP1_PACKET_SIZE_HS, usbDataBuffer, FALSE);
    USB_dmaRxStop(CSL_USB_EP2, usbDataBuffer2,
                          CSL_USB_EP2_PACKET_SIZE_HS, FALSE);

    so the IN reply will be different from the OUT.

    That did not work, and everytime we send a sequence to OUT pipe, we received the same sequence back to IN pipe even though we specify different buffer in the dma functions. That was also shown and verified in the usb urb/packet monitoring.
    Every time we exercise the OUT pipe with a sequence of bytes and then we exercise the IN pipe, the first reply to IN is always what we send previously to OUT. We have to read/exercise TWICE the IN pipe in order to give us the original content (0x0202).

    It seems that the endpoint FIFO transmits back whatever it received lately regardless of the buffer used in the csl dma functions.

    That is why I turned to the USB queue manager and the CSL functions for it, to see if I miss something obvious there.

    In any case, is there any working example that we can use, whereas the IN and OUT pipes will be different?
    Is there any example that whatever is being read from the host on IN, to be different than what has been sent from the host to OUT?
    Is there a way, something that we can do, to avoid the FIFO OUT<->IN problem or some additional documentation on the CSL USB queue manager?

    Please for any help.

    Regards,
    Christos

  •  Hello Cristos,

    CSL USB module is configuring the address of Rx and Tx FIFO to the same value. This is the reason for the issue you are observing. Please use the attached csl usb code modified to use different address for rx and tx FIFO(In API USB_initEndptObj). Please note that this modification will change the behavior of original usb examples (poll/int/dma) provided by TI with the CSL. You need to read the IN FIFO twice to get the data transferred to OUT FIFO from the host. CSL USB examples 1, 2 and 3 are simple applications which just demonstrate the reading and writing of FIFO. More effort is required to modify them to develop advanced USB applications.

    Please refer to USB example 4 and 5 which shows implementation of USB Mass Storage Class and Audio Class applications.
     

    Pratap.

    csl_usb.zip
  • Pratap,

    Thank very much.

    Your modification does work indeed.

    I was also trying this direction of FIFO addressing by doing this modification

    /** USB IN End point FIFO start address                                      */
    //#define CSL_USB_IN_EP_FIFO_START                    (0)
    #define CSL_USB_IN_EP_FIFO_START                    (0x800)
    /** USB OUT End point FIFO start address                                     */
    #define CSL_USB_OUT_EP_FIFO_START                   (0)

    in csl_usb.h but for some reason it did not work as it should, your code though in csl_usb.c does a better job and solves the problem.

    // CSL_FINS(usbRegisters->TXFIFOADDR,
    // USB_TXFIFOADDR_ADDR, CSL_USB_IN_EP_FIFO_START);

    CSL_FINS(usbRegisters->TXFIFOADDR,
          USB_TXFIFOADDR_ADDR, 16+128*(epNum-1));

    That is IMHO something that TI should ammend in their CSL  in the first place because it is basic FIFO functionality. I do hope someone is reading this and  include something like it in the next release.

     

    Best regards and thank you again,

    Christos

     

  • Christos,

    This fix is from TI folks,

    You will see this change in the next CSL release.

    Pratap.

  • Pratap,

    That is good, at least in the next release this will be fixed.

     

    Yet again I envy  since you managed to have the proper support. Although I have a ticket opened in TI for the issues we've faced in the TMS320C5515 USB,  for this same question that you send me this modification, it has been answered from them in an entirely different way, they said that I probably have misplaced the C5515/C5505 #define in csl_general.h, I really dont know what to say about that.. I'm just dissapointed from them.

     

    Best regards,

    Christos