Manuel Koeppen

M52223 USB Unstable when using USB2.0 Hub

Discussion created by Manuel Koeppen on Sep 5, 2016

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

Outcomes