Software Support > PowerMAME
USB problem isolated!!
2600:
I'm not sure what Randy is going to do and not sure if I should put in my $02 on the problem, but we do it with everyone else so as long as I don't give away his secrets should be fine. I don't want to give out too much of how Randy's controller works on the USB level so it's dumbed down. The important thing is how to avoid the problem.
I believe the problem is do to the way the OHCI USB controller and some 2.0 hubs work. The controller and hubs can make some commands happen faster compared to a UHCI controller. This is perfectly USB Spec legal. Speculating, but usually when this happens the firmware of the device is not fast enough to deal with it and the buffer is getting overwritten or some other incompatibility with the OHCI controller.
To avoid this problem for now in software, you can do like Mike has done and add delays, flush buffers, etc and *hope* you don't see it again. So that means not only a new dll, but new ocx, and new applications that needs the new ocx or dll. Applications can also minimize the use of commands that use multiple stages.
In hardware, if you have an Intel and Via chipset or use a Via USB card you are fine if you don't use a 2.0 hub. Everyone else including ATI chipsets(winkie winkie Mike) then you may get this problem.
For hubs, I imagine it can happen with a lot of USB2 hubs on USB2 systems. Maybe not on Via USB2 hubs but I don't know what their marketshare is and don't have a VIA USB2 hub.
My $.02 and I could be completely wrong, but it would be just plain wrong and misleading to put the blame on Nvidia chipsets.
Randy, or anyone else for that matter, if there is any information that you think is incorrect let me know and if it is I will remove it. If you need any of the USB analyzer captures let me know, not sure how much use they would be though.
MikeQ:
If each report is sent synchronously and each report fits in the devices input buffer, how could the buffer get overwritten?
There is an obvious timing issue involved here but I'm confused as to why synchronous writes appear to have an asynchronous quality to them. The offending command consists of 4 hid reports of the same size. I send each of the 4 reports synchronously. It appears that when I write the 4 reports one after the other, they clobber each other. In theory, I should not be getting control back in my driver to send the next report until the first report has finished.
What component is performing the blocking and reporting to the OS that the write has been performed?
Just out of curiosity, I'd like to see the analyzer dumps. This is my first venture into USB devices so you've got me interested in fully understanding this. The workaround will suffice for now though.
2600:
--- Quote from: MikeQ on March 22, 2006, 09:15:42 am ---If each report is sent synchronously and each report fits in the devices input buffer, how could the buffer get overwritten?
--- End quote ---
Here's one way: Some of the reports are received back to back. The report includes a setup and data packet. Once the report is received, the device starts decoding the setup packet. During this time, the next report is received which overwrites the previous data packet before the device has decided what to do with the data.
--- Quote ---There is an obvious timing issue involved here but I'm confused as to why synchronous writes appear to have an asynchronous quality to them. The offending command consists of 4 hid reports of the same size. I send each of the 4 reports synchronously. It appears that when I write the 4 reports one after the other, they clobber each other. In theory, I should not be getting control back in my driver to send the next report until the first report has finished.
--- End quote ---
--- Quote ---What component is performing the blocking and reporting to the OS that the write has been performed?
--- End quote ---
Ok, before I get to the next questions. I'm not a windows programmer. Although, we may use windows a bit, we really use a real time linux usb stack that we wrote. Second, I'm on the other side. Designing the device and FW for it. I've helped the application programmers a bit, but am standing on less firm ground.
Your reports are being sent out fine. All four of them are there. Even get back an Ack saying it was received. But some of that is really low level and done in HW.
Let's say your application is really low level. As far as your application is concerned, everything is fine. Data was sent out and received fine. The device is where the probelm is. It received the data just fine.
With Windows though are you even that low enough of a level. Aren't you merely sending it to the next buffer or part in the OS or even the stack that says, I'll take it from here. The HW or Stack would probaby do a retry a couple of times before it complains to you that there is a problem.
Kind of like file I/O. Just because you write a file out, doesn't mean it is actually on the disk. It could be in some cache or temp storage getting ready to be written, but the OS or HW is taking care of that for you.
Some of that is simplified to get my point across, but should be correct in general.
--- Quote ---Just out of curiosity, I'd like to see the analyzer dumps. This is my first venture into USB devices so you've got me interested in fully understanding this. The workaround will suffice for now though.
--- End quote ---
Sorry that last part was meant for Randy. I'm assuming he'd give you permission, but just want to make sure. The part I'll clip out isn't too terribly exciting, but will show the offending part. I'm going to see if I can borrow an OHCI card to get a capture of that as well.
MikeQ:
It is hard for me to say what is going on under the hood since I'm using a Microsofts API. It is bascially FILE I/O mapped to the hardware. However, I have the ability to set (probably only request) flags that allow me to write through any cache and to perform non-buffered I/O. Neither of these seemed to help. However, I can't say what is really happening once I set these parameters.
So what is the solution for the device? I've asked Randy to give permission to see the analyzer dumps. He may chime in on this thread. We could also take this to email if you want. mikeq@unappliedbraincells.com
RandyT:
Please feel free to give Mike any information about the device he needs. He's a trusted party :)
As for the device not being fast enough to pick up the data, this doesn't really sound correct to me. If this were the case, then simply adding gross delays between reports should have corrected the problem. It was my understanding that it didn't. It was also my understanding that there were spec limits on how fast a hub or controller would send reports to a device that has identified itself as a "low-speed" device.
Have I missed something?
BTW, the LED-Wiz is doing a *lot* of stuff. Providing 48 levels of PWM and HW modulation FX on 32 individual outputs without flicker takes a lot of work. But the data coming in should be serviced in plenty of time. We are only talking 8-bytes of data per packet and the receiver is interrupt driven.
And whether this is an Nvidia thing or not, I can't say. But the only other chipset that has reported problems so far is an outdated Intel chipset. The later chipset from Intel works fine. So whatever Intel was doing that caused problems on the early one was changed in a newer version. Coincidence? Maybe.
Thanks, and please keep me updated.
RandyT
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version