USB CPPI4.1 DMA RNDIS Mode Not working for Host Instance (USB1- RX) of AM335x

Moving this to the Starterware forum.

Hello Biser,

                      Thanks for moving this thread to Starterware forum.Is there any Hardware Dependencies for CPPI4.1 DMA Initialization to work in RNDIS Mode for Host Controller Instance.Is there any Errata?

Thanks & Regards

Rama Krishna

Hi Rama Krishna,

I'll make two guesses concerning your problem.

1)  I'll guess that you are trying to use "Generic RNDIS" (also called GRNDIS).  If so, then your problem might be discussed here, on page 19, Advisory 1.0.13, Sitara™ AM335x ARM® Cortex™-A8 Microprocessors (MPUs), Silicon Revisions 2.1, 2.0, 1.0, Silicon Errata, sprz360f.pdf

2) On the other hand, if you are trying to use RNDIS (not Generic RNDIS), then you and I may be tackling the same problem.  That is, we both want to use RNDIS in the Starterware USB software.  My question, posed here, is that some Starterware routines imply (?) they will not work in RNDIS mode. 

"This API will work in both transparent mode and GRNDIS mode."  
[in file cppi41dma.c, the functions doDmaTxTransfer() and doDmaRxTransfer()]

That note seems to imply that these API functions will not work in RNDIS mode.  Is that correct?  (Yet RNDIS mode is exceedingly similar to Generic RNDIS mode, which Starterware claims does work. For example, these two modes behave identically so long as the total transfer size is not an integer multiple of the maximum USB packet size.)

Perhaps we must make changes to the Starterware.  ???

-- Walter Snafu

Hello All,

              Is there any update on this topic?

Walter Snafu:

I did some changes in the cppi41dma.c, in order to work for all the modes(RNDIS, GRNDIS and transparent).It is working as expected for device instance of AM335x for both transmission and reception.It is also working for Host Controller instance of Am335x for transmission, but for reception it behaves like transparent mode(raises interrupt for every 512 bytes).

According to errata, data loss may happen, multiple end points working concurrently, but my testing case is different.Please help me to sort out this problem    

Thanks & Regards

Rama Krishna

Rama Krishna,

I work with the OMAP-L138 (not the AM335x chip), so I don't know how much help I can be, since I don't know your chip.   

I hope my suggestions may give fruitful avenues for you to try.

The first thing I would examine is the mode registers of the AM335x CPPI -- particularly the receive mode for that endpoint -- to make sure it is in the mode you want. 

The second thing I would examine is the direction of that endpoint.  Because it can be confusing.  Using Starterware nomenclature (which is inherited from the international USB spec), the direction is always specified with respect to the Host.  So, if you were in device receiving mode, then you would set the direction as OUT.  But if you are in host receiving mode, then you would set the direction as IN.  Check that.

The third thing I would examine is the receive completion queues (queues 26 and 27, which generate interrupts) and how you have specified the packet descriptors.  This is where things get more confusing.  Things are still a bit mysterious to me, as the CPPI documentation is not always clear, so I might be mistaken.  Let's say you want to receive a large block of data, say, a megabyte.  The CPPI breaks that into 512 byte packets for transmission and reception, then reassembles them at the other end.  You want the interrupt to occur when the entire megabyte has been received.  Now examine your packet descriptors.  You can set it up to use just one packet descriptor (and one large receive buffer) for the entire megabyte reception.  Great!  (That is what I would do.)  You will receive the interrupt, as desired, when the entire megabyte has been received.  Or, you can use many packet descriptors, all chained together, each one pointing to a buffer -- let's assume 512 bytes each -- which is one buffer for each 512 byte USB packet.  In this case, I believe it is possible the CPPI will generate an interrupt as each packet descriptor enters the completion queue.  This would explain the symptoms you have described.  I believe there are ways to avoid this, even when using the chaining method -- and the solution will depend on the specifications you give in the packet descriptors.  In particular, I would especially examine the "Return Policy" (bit 15 of HPD word 2) and perhaps also the "Packet Return Queue #" (bits 0 thru 11, in HPD word 2).

I hope this is helpful.

-- Walter Snafu

Hello Walter Snafu,

Thanks for the quick response.

                           I am using AM335x chip and tried the all the combinations mentioned above.All are working as expected, but as mentioned in the first post Host instance reception is not working in RNDIS/GRNDIS Mode. 

Regards

Rama Krishna