M52223 USB Unstable when using USB2.0 Hub

[koeppen]

One of our customers has some problems with this CPU when it is connected to a USB2.0 port via a USB2.0 hub. Without the hub, everything works fine!

The software is using no OS and is using the CMX USB Lite Stack, available here:

http://cache.nxp.com/files/32bit/software/protocol_stacks/ColdFire_USB_LITE.exe 

So I went back to the eval board M52223EVB and flashed the original example from the ColdFire_USB_LITE.exe

ColdFire_USB_LITE\usb-peripheral\projects\CodeWarrior\mcf52223\hid-demo\hid-demo.elf.S19

I didn't even compile it myself, the binary was in the distribution. Still, I can reproduce some bugs with this.

In the attached zip file m52223evb_test.zip, you find the libusb0 driver and an inf file that will make windows use the libusb0 driver instead of the hid function (you need to use keyboard when installing because the example makes your mouse move back and forth...)

The libusb0_test.exe just cyclically requests the product name, source is also included (Purebasic). You need to start 2 instances of the tool like in 2 Command windows.

After a few seconds, the firmware locks up totally and you cannot communitate via USB any more.

I already found out that the MCF_USB_CTL_TXDSUSPEND_TOKBUSY is not reset in this case, so the USB unit does not transmit any more packets.

The "funny" comment in the original CMX code:

          /* Dnager: if a setup frame will be received not in idle
             state, then the TOKBUSY will not be cleared,
             and the whole USB will not answer any more.*/

lead me to this. And so I added in line 1468, in the state EPST_STATUS_TX just before the line ready_ep_rx(...:

if(is_stp) goto idle; //make sure TOKBUSY is reset!!!

I don't know if this is a good fix but it prevents the firmware from being stuck, but nevertheless some setup transfers fail (shown as error in the libusb0_test). So it is not fully fixed by this.

Also this is not the only problem. It seems, sometimes (after hours..) the CPU sends the data with the wrong endpoint number (e.g. it sends the config request response to our interrupt endpoint that transfers adc data). That totally confuses the PC side . I have no idea how this could be a firmware problem, as the CPU uses different registers for each endpoint.

Again, all this only happens if the device is connected via a USB2.0 hub to a USB2.0 port.

Any ideas ??? - I'm out of ideas right now...

Thanks for any help.

Manuel

Original Attachment has been moved to: m52223evb_test.zip

[TomE]

> It seems, sometimes (after hours..) the CPU sends the data with the wrong endpoint number

> (e.g. it sends the config request response to our interrupt endpoint that transfers adc data).

That sounds like an "interrupt hazard". I suspect you have some USB code running and accessing a structure, and then an interrupt happens and that runs some other USB code that accesses the same structure. Either the first code was modifying the data and it was in an inconsistent state when the second one ran and read it, or the second one modified the data, corrupting it for the first one. Does the CMX code have "lock functions" around structure accesses, and have you implemented them, or just "stubbed them out"? Is the code consistent about where it accesses the USB controller registers from, or is it possible you could have some mainline code accessing the controller and then have an interrupt routine accessing the registers as well?

This could be a "design problem" (bug) or it might be you're using the code in a way the original programmer didn't expect ("to our interrupt endpoint").

> From what I know the old CMX USB stack really do not support USB hub

I didn't think that should affect "devices" that much. We have used an SMX USB stack, acting as the (far more complicated) "computer end" in a product. As we used it, it didn't support hubs at all. That would have required a different "module". But I thought that was only a problem for the "host end" and simple devices shouldn't care if there's a hub in the way, or how many hubs are in the way.

It is possible that the addition of that hub has changed the TIMING of the USB operations, and has exposed a timing-related bug in the CMX code, possibly due to when interrupt routines run.

Tom

[koeppen]

Thanks, Tom. I also don't think that I can't expect it to work. Hubs ARE supported and in general, it works.

I searched the forum of course and found nothing useful to my specific case.

I agree that the timing changes by using the hub, actually quite dramatically because the hub does so called split-transactions.

Anyway I don't see any possibility for any race condition in the code. There are no locks. I only send data from the USB interrupt itself, when SOF interrupt occurs, so there is only one place where CMX code runs, nothing in any main loop or so, just the IRQ. Also the CMX code is written in a way, that everything is "per endpoint", even the CPU registers are "per endpoint", so there is no variable that changes from one endpoint number to another and back or so.

Also that wouldn't explain why sporadically, setup transfers just fail.

The errata suggest that there are hardware bugs in the usb core, but they are (in device mode) only supposed to cause problems when you use a full-speed hub with a low-speed device. Nothing stated about a full-speed device with high-speed hub.

I also contacted CMX even before writing to this forum. They do not support this old code, but they are unaware of any bugs in it, not even the freezing which is easily reproducable. Also they haven't touched the M5222x since then, and would need to reintegrate this hardware support into their current stack (at additional cost). They are of course very confident that that would solve all our problems but I'm not so sure. Anyway they were very kind and even offered a money-back guarantee if it doesn't work so I'm tended to try that, as I am out of options.

Best  regards,

Manuel

[TomE]

Here's another option.

How about getting hold of a DIFFERENT (and assumed working) Driver for the hardware. You wouldn't expect to be able to use it "as-is", but comparing the way it manages USB transactions and the hardware and comparing it with the CMX code might show up differences.

If you have the software with the full development history (and commit logs), you might even find a previous fix for something like the problem you're seeing.

The obvious choice is to clone the current Linux repository, and then start looking through the sources and "git log" of relevant files. You should probably clone the Freescale ones:

http://git.freescale.com/git/cgit.cgi/auto/linux.git/

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/

You can also browse the directory structure and files here:

http://lxr.free-electrons.com/source/drivers/usb/phy/

http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/

What about MQX?

http://www.nxp.com/products/software-and-tools/run-time-software/mqx-software-solutions/mqx-usb-host...

uTasker might have something:

http://www.utasker.com/kirin3.html

Googling for unusual controller register names (SOF_THLD) found this:

http://www.eistec.se/docs/contiki/a00230.html#a5567027779ec927376c0d8a60d53fb24

It also found this, which implies that controller might be used in the Kinetis chips too. Maybe there's some software for them:

https://developer.mbed.org/questions/6318/K64F-USB-Host-IRQ-Interrupt-Not-Triggeri/

Another thought:

> It seems, sometimes (after hours..) the CPU sends the data with the wrong endpoint number

That's something you should be able to detect in the embedded code, if you can clearly define "wrong". If this is a changing number, then you should be able to have the "current right one or ones" stored in a global somewhere so the code that is about to send the wrong number can check and see if it is about to. They you should be able to breakpoint that, and then browse the calling stack and all the data structures to try and work out how the code managed to make that mistake. If you don't have an ICE with a good debugger, then get one. If you can't, then start printing reams of stuff and dumping memory when this happens.

Tom

[miduo]

Hi,

What you had encounterd is normal. From what I know the old CMX USB stack really do not support USB hub, same case for some other USB stack. Anyway, if possible, you may also contact CMX directly for more detail/root:

CMX Systems, Inc 

[TomE]

Have you searched this forum for any previous posts similar to yours? There are quite a few matching "USB CMX", but I haven't gone through them in detail to see if any of them match your problem.

Here's the original announcement for CMX Lite, from 10 years ago:

http://www.cmx.com/press38.htm

It may not have had any work done on it since then, or at least since 2007 (the date on the installer).

The page for the stack has the code listed as Revision ZERO, and states:

    15 Oct 2008 Software offered 'As is', support provided on NXP Communities only.

The "Click-through License" states:

SUPPORT. Freescale is NOT obligated to provide any support, upgrades or new releases of

the Software. If you wish, you may contact Freescale and report problems and provide

suggestions regarding the Software. Freescale has no obligation whatsoever to respond

in any way to such a problem report or suggestion.

There is a (2007) CMX Price List in the package. Maybe you should contact CMX and consider buying their current version.

Tom