USB CPPI DMA Usage

Anybody please help on this

Hi

The CPPI41-DMA consists of multiple components, 1) Queue Manager 2) CPPI-DMA channels 3) CPPI-DMA schedular

1) The Queue Manager is responsible for management of queue operation and linking of cppi descriptors stored in each queue.  Hence Queue manager requires two memory regions,

a) memory regions requried to remember the sequence or linkage between descriptors in the queue, which is called linking RAM.

b) descriptors memory regions (upto 16 regions are supported).  The descriptors of same size is

2) There are 30 Tx/Rx CPPI-DMA channels for each both usb controllers

3) CPPI-DMA schedular table for scheduling the active tx/rx dma channels.

=============================== Q & A ===========================================

1. Why do we have CPPI Mem1 Base Address Register when the Location of data buffers is already contained in the Descriptors we define?

Ans: This is linking RAM memory region required for linkage of descriptors in the queue. (not for the data buffers in the descriptors)

2. In Rx Channel N Host Packet Configuration Register does Buffer manager and Buffer ques refer to Queue Manager and the some of the Descriptor Queues respectively?

Ans : The buffer manager referred here is queue manager number (default 0).

3. I have all the descriptors of the same size. Do I still need to define 16 memory regions and give their addresses and sizes in Queue Manager Memory Region R Base Address Register and control registers or can I use only a single large enough memory region? If yes what to write in the remaining  Queue Manager Memory Region R regsters ?

No, one regsion is sufficent for descriptors of same size.  do not wirte anything in unused regions register.

4. In CPPI DMA Teardown Free Descriptor Queue Control Register (TDFDQ)  why is there mentioned 2K queues when there are only 156. Why there are so meny teardown descriptor queues assignments in different registers. For example in TX Channel N Global Configuration register etc. 

No only 156 queues are available, not 2K queues

5. In Rx Channel N Host Packet Configuration Register A (RXHPCRAn) and B. What are host type packets? And why these queues are needed. What are first, second RX buffer in a host type packet?

Each rx dma channel can have four rx free buffer descriptors queues, which can be configured in A and B registers. These register make significant more in embedded descrptors are used. In case of host packet descriptors all the 4 fdb queues are configured to same queues.

Regards

Ravi B

Hi,

I am grateful to you for your reply. Just one two more things.

1. Regarding question 1. The CPPI Mem1 Base Address Register (DMAMEM1BA) and CPPI Mem1 Mask Address Register (DMAMEM1MASK) that I am mentioning is separate from those of linking ram region registers Queue Manager Linking RAM Region 0 Base Address Register (LRAM0BASE). So that why it is require when linking ram region address is already mentioned in LRAM0BASE register?

2. After configuring everything for the DMA(setting and pushing descriptors on queue etc) how do we actually initiate a transfer for example in host mode tx do we need to set TXPKTRDY bit or the transfer starts automatically and sends an OUT token? What actually triggers a dma tx transfer for host in this case? I  have configured everything but get tx completion interrupt when I push Packet Descriptor on the queue.

Regards

Mughees

The cppi41 dma driver does not use the DMAMEM1BA and DMAMEM1MASK register. For Tx operation, after the pushing the tx descripotor TxQueue, you need to enable the DMAENAB bit in TXCSR register, you should not set the TXPKTRDY bit. The TXDMA once enabled and input queue is non-empty it will fetch TXBD and move the data to CPPI-FIFO, the XDMA transfer the data from CPPI-FIFO to TX-endpoint FIFO, once the fifo is full XDMA sets the TXPKT ready automatically.

Regards

Ravi B

Hi Ravi,

Thanks, many confusions have been cleared. But I am getting nothing on the bus after I enable dma. Let me tell u the flow I am implementing. Note the following works if I use cpu to fill the FIFO. I need to do a simple transfer of 32 bytes in transparent mode. MAX packet size is 64 bytes. Here is the flow:

1. Initialize the DMA. Descriptor size is 32 bytes. Memory for descriptors is 32 byte aligned. Link Ram0 region is 4 byte aligned. Link ram 0 size is set according to 512 descriptors. There is only one mem region for descriptors with its start index for link ram initialized to zero. 

2. Then I initialize TXMAXP,TXTYPE,TXCSR,TXFUNCADDR and everything to setup a normal transfer. Note this works if I do not use DMA and use cpu instead to fill FIFO . Then I clear AUTOSET,FRCDATATOG,set DMAMODE.

3. Now I Set DMA in Transparent Mode. Initialize a single Packet Descriptor in the memory. Return queue is 93. Enable TX channel related to the endpoint. Set only a single entry for this endpoint 1 in scheduler table. Enable the scheduler. Now I push packet descriptor and its size on the  TX 32 queue using CTRLD register. The corresponding pending bit for queue32 ONLY gets set.

4.Now I enable DMA in TXCSR register but I get nothing on the bus and no completion interrupt. No out tocken no nothing.

I have also tried interchanging steps 3 and 4 but no success.

Best Regards.

Thankyou

Mughees,

Are you sure you're posting the packets to the correct queue for the endpoint you are using?  I think they are predefined; see the table 'Allocation of Queues'.

Regards,

Bill

Hi Bill,

Yes I am setting it correctly. Because when I push the descriptor on the queue the pending bit for that queue gets set. I verified it using the queue pending register. I am using queue 32 to service tx endpoint 1. For return queue I use queue 92.This is given on page 2566 and 2567 of the Technical Reference manual for dm8148.

Regards

Mughees

Mkae sure you have set the DMAReqMode (D10 bit) of TXCSR registert.

Regards

Ravi B

Hi there,

I have the same issue here with a Mistral DM8148 Eval board. I'm using USB0 with CPPI DMA.
Here is an example for EP2 TX:
Init:
1. Setting up descriptors: each is 32byte and there is a total number of 32. They are aligned and stored in the external RAM.
- I'm using the first 30 descriptors. 0-14 for TX and 15-30 for RX. So for TX EP 2 I'm using desc[1].
  Descriptor type is 0x10, packet type is USB
2. Memory region base 0 is set to the start address of the descriptor array
3. Memory region ctrl is set to 0 (32byte desc, 32 the size.)
4. Linking RAM has its own area in the external RAM, its size is 32*4byte and aligned.
5. Scheduler is set to schedule all endpoints as an RX(0-15) and a TX (0-15)
6. TXMODE, RXMODE and AUTOREQ registers are set to 0
7. For endpoint 2 I use the same init as for normal transfer, except DMAMODE and DMAEN are set and AUTOSET is cleared. 

Sending a packet:
1. Data buffer is allocated in a non-cached area in the external RAM.
2. In descriptor buf_len = orig_buf_len = packet0 desc len field = transfer len (256byte), Source port is 1 (Is it ok?), channel num is 0, Return queue number is 94
3. Using EP2 TXGCR (0x47402820u) -> setting up the same 94 return queue
4. pushing the descriptor to queue 34 (address | 2 (because it has a size of 32byte)
- I see that queue 34 has a pending transfer
- In linking RAM I saw 0x00004001 is written with a 4 byte offset  
5. Enabling TXGCR channel.

Unfortunately nothing happens.
What am I doing wrong?
I'm using CCS5 and SYS/BIOS OS.

Could you please help me?

Regards,

Peter 

Mod: Problem solved. The descriptors were stored in a cached area instead of a uncached area.

Hello again,

I have two more questions about USB CPPI DMA mechanism. I successfully implemented TX and RX DMA and they are both working. In case of TX transfers I use Generic RNDIS and RNDIS mode which are correctly  working, however I would like to use GRNDIS on RX side too, but it is not working. I use the same method at RX side as at TX. Is there anything I should do beside I do at TX transfers for an RX transfer to get it working?

I also tried to use Teardown mechanism, but it seems to me it is not working. I think I setting up something in a wrong way.
Could you please explain what should I do to get Teardown working?
I'm testing teardown with an RX channel ( EP3 is configured for RX bulk ) . At the moment I tried two things :
1.a, Adding a teardown descriptor to the  RX submit queue ( free descriptor queue number 2 )
   b, Setting DMA channel 2 to indicate a teardown
   c, Setting Mentor core registers

2.Same as first, but I added the teardown descriptor to the RX completion queue ( queue num 111 )

In both cases when I read the completion queue of RX EP 3 I've got a strange memory address somewhere in the external memory, but always the same.
What am I doing wrong?

Regards,
Peter 

Teardown seems to working, I forgot to set the teardown queue number in the Teardown free descriptor queue control register. I said seems to work, but actually I think it is not, but let me explain it through a GRNDIS RX example.
As I wrote I have some trouble with GRNDIS receive too. This example will show what it is.
The application is a CDC-serial device and uses a self protocoll to test CDC IN and OUT speed.
The device receive transfer settings are: Buffer size: 2k, Transfer size 2k, RX mode is GRNDIS, EP3 is used, RX submit queue number is 3, completion queue is 111
1. Host OUT transfer with test length
2. Host OUT transfers 512bytes * test size in 4k blocks.

So it is a simple situation. Sometimes it is working correctly. However sometimes the device got an interrupt after some 2k packets with a length of 64byte data instead of 2k and sometimes there is no interrupt after 2k received. I checked the USB bus, the packets are there and they are correct. The host is a PC.
In case of those situation the EP3 queue is freezed. I saw the descriptor is not in the RX submit queue, but it is not in the completion queue also. So the DMA still processing that descriptor.
However I'm unable to teardown this channel. In this case I pull out and  plug in the USB again and in this case EP3 channel is being tore down. But when I start the test again I will have nothing. Nor interrupt nor descriptor. So I assume that descriptor is still being locked by the DMA.

Could you please help me in this?