USB Host support for MCF532x

[Viper7]

Hi,

I can not believe the lack of software support/examples regarding the USB on the MCF532x processor. 

I am particularly interested in the USB Host side. 

I found the example stack from CMX, but unfortunately is not ported for the 532x family and from the looks of it, would take too much work to port.

Are there any examples/sample code out there for this specific processor that I missed or is my only choice to start from square one and write my own drivers?  Any white papers regarding this also?

Thanks for the help,

Mike

[Viper7]

Thank you for your continuing support.

I've attached two images.  Screen capture of the registers, and one of the stack variables.

These were taken when I broke the code while stuck in a loop waiting for the characters to return.

The device has one endpoint (1), for both, bulk in and out.

The qtd is linked to go from usb_qtd1 to usb_qtd3,(qdt2 was the data stage and was skipped, I was just trying to see if I could return any data whatsoever),  usb_qtd3 has the ioc (interrupt on complete) bit set.

It seems to execute qtd1 (OUT transfer) successfully, but hangs on qtd3 (IN transfer)

Another note, we have a scope that can trigger on USB packets and I'm seeing a 1ms keep alive packet during idle being transfered, whicih I assume is a good thing.

Now, when the code hangs waiting for the IN transfer, I'm seeing on the scope a repeat transfer of about 5 us (micro seconds) in length and a repeat period of 8 us.  It keeps the period going indefinitly and appears to be thrashing the USB device for the data.  Is this correct operation of the host?

Thanks,

Mike

Edit:  Pay attention to the USB_HOST_HWGENERAL and USB_HOST_HWHOST registers.   They dont comply to what the datasheet displays and are read-only registers.  Any insight on this?

Message Edited by Viper7 on 2008-01-15 03:55 PM

[melissa_hunter]

Hi Mike,

Looks like the host controller is happy. The values in your data structures look ok to me, and none of the registers indicate an error either. Between this and your description of the signals, it sounds like the controller is just continuously retrying the IN transaction. This means that the device is responding to it in some way (otherwise you would get timeout errors and the qTD would eventually be retired with an error status).

So I think the controller is doing what it is supposed to do, and the device is responding in at least some way.  You might want to try a different device just to make sure the problem isn't on that end. Other than that I'm guessing that the problem is in the implementation of the MSD protocol. One thing you might want to try is connecting your device to a PC and using a USB sniffer to watch the traffic the PC sends. Then you can more or less duplicate the packets the PC sends in the 532x driver. Since you already know the PC driver works, you can use it as a starting point. I've found that to be helpful in the past. It is probably much easier to see it in action than to go through all of the MSD documentation.

I hope this advice helps.

-Melissa

[Viper7]

Hi,

I've tried with 3/4 different devices and all have the exact same results.

This may be a dumb question, but how do I know specifically if the host controller is ACK/NAKing??? 

Mike

Message Edited by Viper7 on 2008-01-18 04:00 PM

[melissa_hunter]

Unfortunately there isn't really an easy way to see when the host is ACK/NAKing a packet. At least not from probing the registers. A USB bus analyzer is the easiest way I know of to see what is really happening on the bus including determining how many packets are NAK'd.

[Viper7]

So, there is no real way of determining if the device accepted or threw out the packet?  I need to find out what the device is doing, and currently I do not have a packet analyzer.

[melissa_hunter]

You might be able to get some clues from the MSD specification. It should at least tell you what the device ought to be doing. You might still need a USB bus analyzer to figure out what it is really doing though.

I kind of mentioned this before, but you might want to consider using a USB sniffer. It's similar to a full USB bus analyzer, but it is software only. There are a number of USB sniffers and many of them are free or at least have a free trial. This won't help you for seeing communication between the 532x and your USB device, but if you can use it to watch traffic between a PC host and the device, then it will tell you what the traffic should look like. That in turn could point you to a step you might be missing in your 532x code.

[Viper7]

Hey,

No, I'm not even receiving a zero length packet.  It is not completing the TD, and the QH, and qTD pointers all are correct and incrementing as they should.

The CBW is corret, i verified it in memory and with the documents 100 times.

No matter what, it's not responding to the command, which is an INQUIRY (0x12).

Thanks.

[melissa_hunter]

Could you send me the values you have in your QH when it gets to the point of waiting for a response? If I can see the entire data structure that might help me figure out what is happening. A dump of your USB register values would be good too.

-Melissa

[melissa_hunter]

What is the status of the IN qTD? Is it completing? Does the QH even get to it?

I would expect that the device would send some type of response. Are you just getting a zero length packet back from the device? That would be the obvious thing to retire the IN qTD without generating an error. Is that what is happening? If you have access to a USB bus analyzer, I would recommend using it so that you can see the actual bus traffic. That way you can verify if the 532x is really sending the IN packet and then see what the device is doing in response.

-Melissa

[Viper7]

Thanks for the reply.

yes I do have an in qTD set up and ready to go.

I can properly enumerate the device, but when I try to communicate using the Bulk endpoints I do not receive any data back.

All I'm trying to do is send out a CBW block and see if I can receive a response back from the mass storage device in the form of a CSW or even an error, but neither appear.

From my understanding the CBW is correctly set up. 

Another side question.  If I tried transmitting an incorrect CBW, would I not receive back at least an error from the device?   I also check the endpoint status, and they are both returning non-halt conditions.

I would be happy at this point if the device would at least return me back an error.

I'm lost, any help would greatful.

Mike

[melissa_hunter]

Hi Mike,

Do you have a transfer descriptor (qTD) setup to receive the IN packet from the device? The USB host controls all of the traffic, so the host does have to initiate all traffice. If you don't initiate an IN packet on the host side, then the device won't be able to respond. Since you said your asynchronous list is empty, I'm guessing you are missing the IN qTD.

Hope this helps,

Melissa

[Viper7]

Mac, thanks for the reply and yes, I stumbled upon that code.

I'm trying to communicate with a Mass storage device.  I can enumerate the device fine, but when I try to send an actual command out the bulk endpoint, I never receive a response, not even an error.

I send out the CBW fine, but upon awaiting for the IN packet, I hang.  It doesn't throw an error at all.  The only status I get back is that it's reporting that the asynchronous schedule is empty (USBSTS),which I'm assuming it is, because it's hung waiting for IN packets that it never receives.

Any help on this?

Mike

[macl]

Hi Mike,

Have you seen the sample code project that is available on the 532X product website?

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCF532X&nodeId=0162468rH3YTLC00M92076...

download MCF532XSC

It isn't a full stack, but it does have working USB sample code.

Mac