Truncated packets using USB on MCF54455

[Thad]

I am porting a driver originally written for the IMX31 to run on an MCF54455.  I am developing on the MCF54455EVB and when running Linux the USB works fine, so the hardware is fine.  As far as I can tell, I am initializing the USB core and setting up the registers no differently than on Linux, but I can not even reliably send a SETUP message.  My QH and TD records all look good, are mapped into valid RAM, and I see most of the data is making it onto the bus when I sniff the line, but packets are often being truncated or not acknowledged.  I am not even out of setup yet, so the Periodic queue is empty and we having nothing else on the async queue but this setup message.

The status being written back to the TD has the Transaction Error and Halted bits set and the CErr count has been decremented to zero... probably because the device (a storage dongle) did not succesfully responded.  On occassion the config message will make it and the device responds, but then that message is truncated.

Other info:  I am using the internal tranceiver, so connecting at full speed not high.

My instincts tell me this is a timing problem, that I am running past the end of the frame or something like that, but I can't find how to verify or adjust for that.  I've been through the EHCI spec and the MCF54455 spec and nothing jumps out at me, especially considering the usual PCI bus timing issues don't apply with this embedded core.

Anyone have any ideas what the most likely cause is?  Any suggestions on how dig into it a bit deeper?  Most of my USB work has been at higher layers, so this is new territory for me.

Thanks.

[Thad]

This is just a follow-up in case anyone is curious what the fix ended up being.  The driver was not properly handing some hub characteristics fields, so the transaction translator think time was not set correctly.

[Thad]

Yes, cache coherency was one of my first thoughts, and I am rather confident now that it is not the issue.  I have verified that flush and invalidate of cache lines is happening at all the right times and that the buffers are all aligned to cache line or page boundaries as required.  Indeed, it now looks like the entire packet data is making it to/from the bus (see previous post), but the handshaking is not happening.  Again, my instincts shout 'timing' at me, but even with this snazzy new USB sniffer, I am unable to tell.  As I understand it, the coldfire USB module is generating SOF packets automatically, and processing of the queues is pretty much all done by the hardware also, so I'm at something of a loss as to what to tweak.

[Thad]

As I dig a bit deeper into this protocol trace, I see that most of what it labels as 'truncated' packets are really just missing the ACK.  So the entire packet makes it out there, but the device (or in some cases host) does not handshake.  The time between transactions looks reasonable, so I think the device should be ready.  What sort of problem would cause a failure to handshake when the data is otherwise on the bus?

[Thad]

OK, a bit of progress and some more info.  I realized my QH and TD memory pool is in SRAM, so I upped the USB priority to that as well.  I now consistently send an initial SETUP packet and get the reply every time.  It then fails most times during the SetAddress phase.  About every fourth time makes it makes it past that and fails getting the full length config descriptor.  Again, truncated packets are seen by the protocol analyser.  I would like to see where these packets are relative to the SOF packet, but I can't seem to find how to do that on this analyser.  Anyone have any other ideas?

[kmahan]

Have you tried running with the D-cache disabled to see if it is a mem caching problem?

[Thad]

Thanks for the suggestion.  Unfortunately I just tried the crossbar thing and it did not fix the problem.  Any other ideas?

Thad

[kmahan]

You might check the memory crossbar configuration.  There was a problem with the USB core getting priority access to memory (which showed up in highspeed devices).  By increasing the usb core priority on the crossbar switch the problem was resolved.

Look in arch/m68k/coldfire/config.c

Code:

#if defined(CONFIG_M5445X)        /* Setup SDRAM crossbar(XBS) priorities */        MCF_XBS_PRS2 = (MCF_XBS_PRS_M0(MCF_XBS_PRI_2) |                        MCF_XBS_PRS_M1(MCF_XBS_PRI_3) |                        MCF_XBS_PRS_M2(MCF_XBS_PRI_4) |                        MCF_XBS_PRS_M3(MCF_XBS_PRI_5) |                        MCF_XBS_PRS_M5(MCF_XBS_PRI_6) |                        MCF_XBS_PRS_M6(MCF_XBS_PRI_1) |                        MCF_XBS_PRS_M7(MCF_XBS_PRI_7));#endif

 

--Kurt