Issue with USB host stack communicating to USB hub

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Issue with USB host stack communicating to USB hub

ソリューションへジャンプ
3,031件の閲覧回数
travis_l
Contributor III

I'm having some strange issues trying to get a k40 to talk to a USB hub controller on a custom board.  The K40 is a MK40DX256ZVLQ10 and the hub controller is a TI TUSB2046B.  The custom board is actually an option card for another family of devices that we make adding USB host capability to this older family of products that we make.  The board adds USB keyboard and USB mass storage capabilities only, and then communicates to the host device via SPI bus.  All of this works for a while, but at some point the k40 loses communication with the TUSB2046B hub contoller.  The hub contoller appears to go into suspend state when this happens and sending the USB resume command does not appear to help.  In fact, from the k40's perspective, everything appears to still be working.  I don't get any events notifying my app of the disconnect or suspend status other than an external pin on the usb hub controller.  The only way I can see when this is happening is when the hub goes into suspend or if I get an MQX error that I can write to a connected flash drive (file system error).  When I detect the error has happened, I first attempt to send the USB resume command using the MQX USB host API, but this never recovers the communication.  After attempting to send the resume command, I then attempt to do a hardware reset of just the TUSB2046B hub.  Resetting the hub controller works to recover from this issue about 20% of the time.  The only 100% sure way I've found to recover is to perform a software reset of the K40.

The drivers for the USB keyboard and MSD that I am using are from the MQX example projects provided with Codewarrior.  I am using Codewarrior 10.5 for this project, along with the latest version of MQX.  I have used an oscilloscope to monitor the communication between the k40 and usb hub and have not noticed anything unusual.  There is never a delay long enough to put the hub into suspend state and the keep alive packet arrives just under 1ms just like clockwork.  I've even gone as far as having my EE cut the traces between the k40 and the TUSB2046B and put a USB-A cable on it so I can plug it into my PC to try and eliminate the USB hub as the culprit.  When I do this, the hub acts just exactly as I would expect and never gets hung up as when the k40 is acting as the host controller.  So I'm pretty sure that I've narrowed this down to something in the MQX USB host stack, but I've yet to find exactly what is causing it.

I really need to find out what is causing this and resolve it because this project has gone to production and I would like to not use the software reset as a workaround to keep this system running.  Any advice or ideas about where to look for the problem, or any info that someone might have regarding similar issues would be very beneficial to me at this point.

Thank you in advance for any help you can give me.

Travis Long

ラベル(1)
1 解決策
1,845件の閲覧回数
travis_l
Contributor III

Hi Colin,

As of this week I think I have a sort of fix for this issue.  After working with our vendor and FAE, it was sugguested that a modification to the MQX USBH component was necessary in order to get this to work correctly.  in the khci.c file there is two things that need modified.  I think it was in init_khci there is a place where it sets the initial value of the SOFTHLD (SOF threshold) to 1.  This can be changed to 0xFF (the max value).  The other place is in the function that handles the atomic transactions.  In that function you will find that it is dynamically setting the SOFTHLD based on packet size.  You need to comment out the dynamic changing of the SOFTHLD.  Basically, this threshold sets the number of bytes before the next start of frame boundary that the host stops transmitting because transfers cannot occur when the SOF boundary occurs.  Setting the SOFTHLD to the maximum value gives the host controller the most time to finish the current transactions before the next SOF.  The only drawback to setting the SOFTHLD to the maximum is that the overall thouroughput through the USB bus is reduced.  My project uses keyboard and MSD pretty heavily at times, and I failed to notice much difference in performance.

Hope this helps!

Travis

元の投稿で解決策を見る

8 返答(返信)
1,846件の閲覧回数
c_dawg
Contributor III

I have seen the exact same thing using the K60FN1M0VLZ12 and a TI TUSB2077A hub chip.  I'm running CW10.4 and looking to switch to CW10.6.  If you have one, the suggestion of using a USB protocol analyzer is okay, but far from a solution.  Mr. Long if you resolved this I would appreciate any feedback.  I am really struggling for a solution.  As suggested, I am probably doing something wrong with the USB stack, but the hub chip is supposed to be transparent yet somehow it is getting suspended with out MQX detecting it.

Thanks!

0 件の賞賛
1,846件の閲覧回数
travis_l
Contributor III

Hi Colin,

As of this week I think I have a sort of fix for this issue.  After working with our vendor and FAE, it was sugguested that a modification to the MQX USBH component was necessary in order to get this to work correctly.  in the khci.c file there is two things that need modified.  I think it was in init_khci there is a place where it sets the initial value of the SOFTHLD (SOF threshold) to 1.  This can be changed to 0xFF (the max value).  The other place is in the function that handles the atomic transactions.  In that function you will find that it is dynamically setting the SOFTHLD based on packet size.  You need to comment out the dynamic changing of the SOFTHLD.  Basically, this threshold sets the number of bytes before the next start of frame boundary that the host stops transmitting because transfers cannot occur when the SOF boundary occurs.  Setting the SOFTHLD to the maximum value gives the host controller the most time to finish the current transactions before the next SOF.  The only drawback to setting the SOFTHLD to the maximum is that the overall thouroughput through the USB bus is reduced.  My project uses keyboard and MSD pretty heavily at times, and I failed to notice much difference in performance.

Hope this helps!

Travis

1,846件の閲覧回数
c_dawg
Contributor III

Thank you for the information!  I will be doing what you suggested.

When you talked about a "keep alive," the keep alive is just accomplished by MQX correct?  I never wrote the code to do this and it does work for a while so I assume it is in there.

and

I probably have to hit the documentation harder, but you spoke of a "sending the USB resume command using the MQX USB host API."  I don't remember reading about this.  Is it in the USB Host User Guide?  I guess it doesn't matter.  It doesn't fix the problem, but it is something I didn't try.

Thanks Again,

Colin

0 件の賞賛
1,846件の閲覧回数
travis_l
Contributor III

Hi Colin,

Yes the “keep alive” is accomplished by MQX in the USBH and it’s not necessary for you to do anything in order to make this work. The USB_RESUME is not outlined or used in any of the examples, but it should be in the MQX USBH documentation. I didn’t have much luck using the RESUME command in regards to this issue as I don’t think the bus was suspended, but rather in some invalid or error state.

Best of luck and I hope what I learned is able to help you. If you need more specific information about the exact changes I made, just let me know and I’ll see what I can do to help.

Travis

0 件の賞賛
1,846件の閲覧回数
c_dawg
Contributor III

Travis thank you for the information.  I just wanted to follow up with you on something.

You stated: The hub contoller appears to go into suspend state when this happens and sending the USB resume command does not appear to help.

And:

I didnt think the bus was suspended, but rather in some invalid or error state.

My TI hub chip displays a disable indicator light.  On a forum with TI there forum guys state:

"The PORTDIS output is controlled by the USB Host, the TUSB2077A  receives from the Host the instruction to disable the port in order to  force the device enumeration."

Is the suspend state indicated by the Disable light on your HUB chip (if there is one)?

Have you figured out a way to remove the suspend state with out a reset of the K40?

0 件の賞賛
1,846件の閲覧回数
travis_l
Contributor III

Colin,

The only way I've found that works sometimes is to reset the hub controller using it's hardware reset line. This isn't 100% like resetting the micro, but it does work.

I believe the disable is the same as on my board from what you describe, we are using a Tusb2048 if you want to compare.

Travis

0 件の賞賛
1,846件の閲覧回数
matthewkendall
Contributor V

My suggestion would be to put a USB protocol analyser on the bus. I have used this one before and found it to be reasonably useful.

http://www.totalphase.com/products/beagle-usb480/

They have a variety of different versions at different price points depending on what speed you need, and whether you need Power Prototcol, but they all use the same Data Center software for displaying the results.

0 件の賞賛
1,846件の閲覧回数
travis_l
Contributor III

That's what we are looking at doing as of right now.  Our oscilloscope is fast enough to look at the data packets but doesn't have the capability to decode the messages.  I had been doing that by hand.  At the point at which it appears to go stupid I am still seeing the keep alive packets at just under 1 ms intervals so I never see enough quite time on the bus to put the USB hub into suspend state.  Hopefully the analyser will tell me more.

0 件の賞賛