Hi,
I’m writing a UMDF driver, based on the FX2 example.
My device has 2 HID endpoints and 1 bulk endpoint. Therefore, my driver only deals with the bulk ep.
I have two kinds of applications interacting with the driver:
The first writes vendor requests to the device and waits for a read. The read is usually a packet bigger than the max packet size allowed for the ep (and therefore is broken into fragments).
The second application writes vendor requests only in the beginning to the driver, and later listens on reads. The size of the read packets is smaller than the max packet size.
The first application works fine, whereas the second one fails after a while.
I have hooked a USB analyzer to see what happens, and I see that after a while there are no more IN transactions at all (not even empty ones or NAKs) on the bulk interface. The HID endpoints continue to work normally (meaning the device works properly).
I think that the fact that there are no more IN transactions on the bulk ep are a result of a state where the driver doesn’t poll on this endpoint.
Is this a result of a power management issue? Could the bulk enpoint have been put to sleep because there were no vendor requests from the host’s side?
(I have removed the methods such as OnD0Entry and OnD0Exit from the fx2 example)
Or does this has anything to do with the packet size?
(I did not change any of the parameters regarding the SetPipePolicy and SetPowerManagement methods).
Or maybe none of the above?
Thanks,
Gadi
An addition -
- When running the problematic application, sometimes a reset occurs on the USB line (not always). While the HID eps recuperate, the driver doesn’t. No resets occur while running the first application (which runs okay).
- A certain scenario happens - If I run the problematic application, and it gets stuck, and then I run it again it will be stuck immidiately, from the beginning (no IN messages).
If I run the problematic app, and then the first app (which does IN and OUT transactions all of the time), and then the problematic app again, it will take it time to get stuck again. It’s seems like the first app has released a queue which was stuck. I have no clue why this happens, since the firmware works properly.
Thanks again,
Gadi
Have you verified that when your driver is “stuck” that you have outstanding read requests queued to the pipe? Is it possible that your continuous reader logic is getting tricked into stopping by the error and that it doesn’t pick up again unless you poke it by running the other app?
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@n-trig.com
Sent: Tuesday, January 23, 2007 7:17 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF-based USB driver stops polling
An addition -
- When running the problematic application, sometimes a reset occurs on the USB line (not always). While the HID eps recuperate, the driver doesn’t. No resets occur while running the first application (which runs okay).
- A certain scenario happens - If I run the problematic application, and it gets stuck, and then I run it again it will be stuck immidiately, from the beginning (no IN messages).
If I run the problematic app, and then the first app (which does IN and OUT transactions all of the time), and then the problematic app again, it will take it time to get stuck again. It’s seems like the first app has released a queue which was stuck. I have no clue why this happens, since the firmware works properly.
Thanks again,
Gadi
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I have looked into it with a USB analyzer, and apparently there is something wrong with the read-logic.
It seems that both applications fail after a certain scenario occurs (the one which reads and writes all the time caused a ERROR_OUTOFMEMORY in pParams->GetCompletionStatus() and the one which only read had a ERROR_INVALID_FUNCTION).
My device has 2 HID interrupt eps and one bulk (all IN).
The driver only deals with the bulk ep.
The interrupt eps transfer reports of 8 bytes (ep# 1) and 10 bytes (ep#2).
What happens is, that from an unknown reason, in a certain IN transaction, ep#1 transfers 16 bytes (2 reports connected). This is not allowed according to the configuration descriptor and the report descriptors which the device sent to the host during enumeration,
and a reset occurs on the USB line (I guess that it is because this was an invalid packet).
After the reset an enumeration process occurs, and the bulk ep doesn’t recuperate, meaning the applications don’t work.
(By the way, I didn’t see it happen with ep#2. I don’t see any 20 bytes packages – 2 reports of 10 bytes concatenated).
Looking more into it, I have checked the data member m_speed of CMyDevice, which was updated with m_pIUsbTargetDevice->RetrieveDeviceInformation(DEVICE_SPEED,
&length,
&m_Speed);
and it shows 0x1 - LowSpeed, when my device is actually FullSpeed.
Could it be, that the host thinks it’s a slower device, does slower pollings, and the device (which is faster than expected) has already prepared more packages, and from that reason two of them were concatenated together?
How can I fix this?
Did the speed issue cause the problematic package? Is this what caused the reset?
And is there a way to set the speed parameter? Or at least to find in the location in the code where the wrong value is set?
Thanks,
Gadi
>What happens is, that from an unknown reason, in a certain IN transaction,
ep#1
transfers 16 bytes (2 reports connected).
Maybe this is the hardware issue and not the driver development issue?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
xxxxx@n-trig.com wrote:
I have looked into it with a USB analyzer, and apparently there is something wrong with the read-logic.
It seems that both applications fail after a certain scenario occurs (the one which reads and writes all the time caused a ERROR_OUTOFMEMORY in pParams->GetCompletionStatus() and the one which only read had a ERROR_INVALID_FUNCTION).
My device has 2 HID interrupt eps and one bulk (all IN).
The driver only deals with the bulk ep.
The interrupt eps transfer reports of 8 bytes (ep# 1) and 10 bytes (ep#2).
What happens is, that from an unknown reason, in a certain IN transaction, ep#1 transfers 16 bytes (2 reports connected). This is not allowed according to the configuration descriptor and the report descriptors which the device sent to the host during enumeration,
More than that, if the host is expecting 8 bytes and the device responds
with 16, that’s called “babble”. It is considered a failure in the
endpoint.
Looking more into it, I have checked the data member m_speed of CMyDevice, which was updated with m_pIUsbTargetDevice->RetrieveDeviceInformation(DEVICE_SPEED,
&length,
&m_Speed);
and it shows 0x1 - LowSpeed, when my device is actually FullSpeed.
Does the device have both low speed and full speed descriptors? Do the
descriptors look correct in usbview? The choice of speed is made during
the enumeration and negotiation. The hub will try to connect as
full-speed, and if the device doesn’t respond properly, it will fall
back to low-speed. Your device should show which one it is using.
Could it be, that the host thinks it’s a slower device, does slower pollings, and the device (which is faster than expected) has already prepared more packages, and from that reason two of them were concatenated together?
If so, it’s a bug in the device.
How can I fix this?
Fix your device so that it only transmits 8 bytes at a time.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi,
Thanks for the quick replies.
According to the USB analyzer, my device always works at full speed.
The “speed” column is always FS. Am I supposed also to see something specific in the enumeration process? A certain field which in being transferred?
Does the device have both low speed and full speed descriptors?
It has 2 HID interrupt eps and one bulk. They are all supposed to be FS, as far as I know.
I have set the polling of the HIDS to 1ms in the descriptor.
I made a small experiment and disabled my HIDs in the device manager. Now the speed data member in the UMDF driver showed it was a FullSpeed driver (as opposed to before, when all eps were operating, and it showed LowSpeed).
Could it be that there is a collision between the HIDClass driver of the OS and my driver? And this collision downgrades the entire speed of the device to LS (even though I see FS in the bus analyzer log)?
Can such a downgrade cause the “babble” which I described? That 2 packets are concatenated? Does the host has anything to do with it or is it a firmware issue?
I also saw that the bulk ep also concatenates packets, only there it doesn’t crashes because there are no rules for bulk messages (no template as in HID).
Thanks again,
Gadi
xxxxx@n-trig.com wrote:
According to the USB analyzer, my device always works at full speed.
The “speed” column is always FS. Am I supposed also to see something specific in the enumeration process? A certain field which in being transferred?
It could be a red herring. Low speed devices cannot have bulk
endpoints, and interrupt endpoints cannot be faster than 8ms, so if your
bulk EPs are showing up, it’s not really running as a low speed device.
Could it be that there is a collision between the HIDClass driver of the OS and my driver?
How? Is the HID class driver claiming your device? Are you writing a
filter driver?
Can such a downgrade cause the “babble” which I described? That 2 packets are concatenated? Does the host has anything to do with it or is it a firmware issue?
This is entirely a firmware issue. If your interrupt endpoint
descriptor advertises a maximum packet size of 8 bytes, but it sends a
packet of 16 bytes, that is an error in the device. You have violated
the contract.
I also saw that the bulk ep also concatenates packets, only there it doesn’t crashes because there are no rules for bulk messages (no template as in HID).
No, but if the host asks for 32 and you send 64, it’s still babble.
It’s a device error.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.