TMS320C5535: USB CPPI DMA, Tx packets are not being queued correctly

Hi Nadav,

Could you give details about your testing environment?
Could you post the console output of CSL_USB_DmaExample_Out?
If your source code is different could you post it?

BR
Tsvetolin Shulev

as for the testing environment: I'm using Code Composer 6, and the CSL version is 3.08.00.01.

the Console output of the test will have to wait until tomorrow because I cant run it right now for personal reasons, however assuming I understood correctly what should be printed, the output is as if the test works without any problems.

Nadav,

How are you seeing that queue 60 is being used.

If you look at C:\ti\c55_lp\c55_csl_3.08\inc\csl_usbAux.h code line ~707

 /* add packet descriptor to TX submission queue for the Endpoint */
		/* EP1 to 16 or 17, EP2 to 18 or 19, EP3 to 20 or 21, EP4 to 22 or 23 */ 
 		
	    usbRegisters->QMQN[14+dwEndpoint*2].CTRL1D = ((((Uint32)hpdtx) << 1) &
	                                          CSL_USB_16BIT_REG_MASK) | 2;
	    usbRegisters->QMQN[14+dwEndpoint*2].CTRL2D = (((((Uint32)hpdtx) >> 15) &
	                                         CSL_USB_16BIT_REG_MASK) | 8);

http://www.ti.com/lit/ug/spruh87h/spruh87h.pdf table 13-26, you will see that the only possible queue numbers are 16 and 17.

Its strange that 60 is showing up.

Lali 

I know its weird, queue 60 is one of the unassigned (application defined queues) in the CPPI DMA of the TMS320C5535.
and to clarify, even when I directly try to write into one of the TX submission queues, for example, queue 20, it still goes to queue 60 instead, since its undefined the system doesn't really do anything with it on its own, so... it just kinda sit there doing nothing.
the only way I know its specifically queue 60 is by pausing the program with a debugger and looking at register, the bit that corresponds to queue 60 in the register PEND3 is set after I try filling any of the TX submission queues.

Nadav,

When you single step through the program on CCS, are you entering the snippet of code I pasted above?

Trying to see if it actually enters this routine and please check what the queue value is at this point.
Can you see where in the code it becomes 60?

Lali

for your first question: yes, I do enter it.

for your second question: immidiatly after its done with that part of the code

Nadav,

I don't have any other ideas on why this might be happening.
I have reached out to some colleagues to see if they have any feedback. We have not had this issue reported previously. Do you have another C5535 to test this on?

Lali

Hi Nadav,

We do not know why the PEND3 queue 60 bit is set.

Did you receive the TX completion interrupt? Did you receive the descriptor in TX completion queue? Did the packet you sent actually reaches the USB host? I know for sure the USB DMA example does work and YES to all three questions.

Ming

HI Ming,
I should probably clarify something, the reason i even know this problem happens to me is because:
A. the packets DID NOT reach the USB host
B. I DID NOT receive the TX completion interrupt
C. I definetly DID NOT recive any descriptor whatsoever in the completion queue's,
if any of these three things whouldnt happen for me (i.e: I would have actually received the descriptor's in the completion queue's)
i might have been able to work it out myself and figure it out, because at least i would have a lead to go on.

still, i do appreciate that someone is trying to help me here, so thanks anyway

 

I run the CSL USB DMA example on c55x platforms in the past, here is the USB DMA example should behave:

0. The USB host sends a data OUT request to C55xC55x receives the EP interrupt and gets the data OUT size

1. C55x put the RX descriptor/buffer into the RX queue (with data OUT size)

2. USB host then sends a 512 byte data packet to C55x

3. Once the RX request is complete when (queuePend1 & 0x0400)!=0, pop out the completed RX request and trigger a TX EP interrupt

4. In response to the TX EP interrupt, C55x put the TX descriptor/buffer into the TX request queue

5. USB host then reads a 512 byte data packet from C55x

6. Once the TX request is complete when (queuePend1 & 0x0100)!=0, pop out the completed TX request

I did not check the queue 60 though.

 

As Lali mention above, the sequence is important.

 

The other thing is the following code is important too:

 

   /* This is to initiate filling the Tx FIFO with data for next read operation */
   hUsbDev->dwIntSourceL |= CSL_USB_TX_INT_EP1;

 

without it, the TX will not work.

 

Best regards,

 

Ming

1. The USB host sends a data OUT request to C55x

2. C55x receives the EP interrupt and gets the data OUT size

3. C55x put the RX descriptor/buffer into the RX queue (with data OUT size)

4. USB host then sends a 512 byte data packet to C55x

5. Once the RX request is complete when (queuePend1 & 0x0400)!=0, pop out the completed RX request and trigger a TX EP interrupt

6. In response to the TX EP interrupt, C55x put the TX descriptor/buffer into the TX request queue

7. USB host then reads a 512 byte data packet from C55x

Once the TX request is complete when (queuePend1 & 0x0100)!=0, pop out the completed TX request