code hangs on cppi41dma.c line #1178 for am335x

To add to this,

The registers in questions have been mentioned in other thread about other problems with the usb.... these register are indicates as being protected under an NDA form the am335x, yet the threads point you to other TI chip documents which use the same IP core and these registers are better documented.

the register in question is the "host mode control status register"{at least in the mode i am using it in} and exists per endpoint , the bit it is waiting on is "FIFO not empty" and every other bit in the register looks correct but the fifo never empties.   I cannot find any indication of error yet or why the fifo will not emply. But i do find the claim that its is not documented because of  NDA a bit odd when it is documented on other chips using the same ip core. The registers is difficult to deciper as these other chips map the register in different address spaces and i am finding them by description and offset values. which is a very poor way to find the meaning of bits and identify a problem.

What I really need is TI help to resolve this, it a real show stoppers if i cant keep using the usb for any length of time.

HI George,

I agree that there are deficiencies with respect to the documentation of USB register set in the AM335x manual. As previously stated in this forum , please use the TMS320DM814x DaVinci manual which has the the same mentor core IP and hence the same register set.

The register that you are talking about is the Control Status Register for Host Transmit Endpoint or USBn_HOST_TXCSR register. In the cppi41dma code, state changes are performed in the interrupt handler [ USBHostIntHandlerInternal () - usbhostenum.c] and pipe read and pipe write functions [ USBHCDPipeRead(), USBHCDPipeWrite() - usbhostenum.c]  poll on these states to complete the read or write cycle. Interrupt handler is invoked when there is some event on that particular endpoint. 

In your case the code gets stuck in the while loop waiting for the FIFONOTEMPTY flag to clear indicating that the DMA TX transfer that you have started has completed. In your case an interrupt has come before the completion of the transfer ( a bulk out - command or data out )and the code gets stuck . As you have stated that this occurs when you are in  "preview stream" ( which I presume would be a lot of Bulk IN's and an intermittent Bulk out ) mode I believe that a previous IN should have failed - NAKd or incomplete. 

Are you trying this in fullspeed mode ? Is there a way that you can get a bus trace? With the information that you have given it is very difficult to arrive at why the OUT tx failed. Is there a chance you got a Inerrupt (transfer) IN at this point ?. Could you please try disabling other interrupts except for this endpoint.

Thanks Vineeth ,

thanks for the response,

 By late in the day yesterday , I had already found on the forum, the referenced docs and saw that i was waiting for a fifo not empty, all this traffic is High Speed.

things were a little slow at breaking things and debugging due to other development environment problems not related to the processor so i needed to iron those out to get a better error rate at creating the problem.  One problem for me was that  i am sending the stream out ethernet and i had some problems on the PC side with the stream stopping due to pc code problems, i finally got that side stable yesterday and I can break it a lot faster now .

 As fror a bus trace, I am using the development board and my USB bus trace tool slows debugging a lot when running in conjuction with code composer so I sometimes leave that as a last resort testing solution. Especially since so much of my stuff wass working correctly and such large amounts of data were succesfully moved.

 very late yesterday I was able to figure out when to start and stop the tool and the debug session in such a way as to not interfere with each other so much, I then found that it is true that the problem is a NAK for the last bulk out, and I also found that the problem is because of the last frames bulk in being incomplete.  this problems occurs only when the previous frames usb transaction is an exact multiple of the bulk packet size. It appears that i get one extra bulk in for the device with no data bytes, this goes unread and the last part of the transaction were it reads PTP status also does not happen from the resulting error, I did not detect this, so the sending of the request for the next frame's bulk out is where it hangs up.

Today I have to figure out if I am doing something wrong on the read data side or if the device is just doing someting nasty and how to dance around it , I may also need to figure out whether a different model camera does the same thing or not. hopefully i don't have  to do a model specific fix.

We never see this on a USB direct to PC connection to the camera but we are also using a driver provided by the manufacturer and they may have coded in a dance around for this problem as the have a lot of model specific code in the package.

In any case , I have an path to follow now and hopefully i will come up with a good solution.

Thnaks again for tyour response.

Hi George ,

I hope you are operating the cppi dma in transparent mode rather than in GRNDIS. If yes, then this seems to a logical issue with the code . In transparent mode of operation  its the code which pokes the controller to generate an IN after processing the already received payload. Hence extra INs would happen because of some error in the code. There was a PIO mode bug which  I discovered and fixed in the USB stack but my belief is that It would not affect you.

Hi Vineeth,

the mode is the same as in the USB stick demo, My code is really a heavily modified port of the PTP example in stellarisware.

 I am pretty sure that the behaviour I am seeing is in the camera or maybe part of the PTP spec, It happens the same way on two different model cameras from same manufacturer.

In a normal process, there is one more bulk in needed after the end of the data portion which has the transaction status, in problem mode, the empty packet get read instead of the status packet, so I leave on an error since i never really read the status , and then the next bulk out is where this gets stuck, since the camera wants to send one more packet and will not accept the command. it really wants to finish by sending the status packet. 

fortunately it is easy to detect when i need to do a dummy read so this problem is history, unless other untried cameras do not do this thing, a problems for later.

George

Great.  Do let us know if you have other issues.