Author |
Topic |
|
3963
85 Posts |
Posted - 27 Mar 2006 : 17:21:09
|
Since we've migrated to 4.20.40 we've begun to get an intermittent "Error 87" during reads and writes. Sometimes it's recoverable via retry, sometimes it's not. The odd thing is that 87 translates to "The parameter is incorrect."; the parameters don't change on retries, and the USB code is very similar to that used on the windows PC (which has no errors) and the same as we used on the previous CE build 4.20.28 (which ran for months without error). I'm pretty confident it's not our application (never say never!).
Any ideas? Recent USB subsystem changes? Is Error 87 now a generic error? If I could reproduce it reliably enough, I'd use the USB sniffer to look for more info. I've got a unit running via debugger, but this unit hasn't manfested the error for a couple of weeks. |
|
3963
85 Posts |
Posted - 28 Mar 2006 : 18:53:22
|
Ok. We have an "ESD Simulator" (aka static gun) in house, so I'm now in a position to definitively say that Error 87 is NOT the real error (on Windows PC, I'd typically see "CRC Error" or some other communications error), but some sort of generic error. |
|
|
akidder
1519 Posts |
Posted - 29 Mar 2006 : 09:38:49
|
Thanks for the update. A few follow-up questions:
- Am I correct that these are errors that your application gets when it writes to the USB driver? - Is this an upstream USB driver? (e.g. to host PC) - Which CE driver are you using for USB? - Is data getting dropped? Does the data go through when you retry? - I'm not clear what the ESD gun has to do with this issue. Please clarify. - Let us know how we can we reproduce this issue.
|
|
|
3963
85 Posts |
Posted - 29 Mar 2006 : 12:01:05
|
- Am I correct that these are errors that your application gets when it writes to the USB driver? Reads or writes to driver.
- Is this an upstream USB driver? (e.g. to host PC) Downstream.
- Which CE driver are you using for USB? Uh, mine. It's an HID driver; I forgot we weren't using the OS driver like we do on the host PC version of the application. Maybe the generic Error 87 is my fault.
- Is data getting dropped? Does the data go through when you retry? The entire *device* is dropped (at least on the PC; haven't completed testing with CE yet). Retries help sometimes (obviously if the device is dropped, they don't).
- I'm not clear what the ESD gun has to do with this issue. Please clarify. We're trying to correlate the (apparenly recent) USB communications failure between CE and our device with something; I've long suspected we have an ESD hardware issue related to USB comm and our boards. Now we know we do. It is just not clear why we haven't had these problems in the past (I suppose there may be more than one thing wrong).
- Let us know how we can we reproduce this issue. The ActiveSync connection seems resilient to the ESD; if you can assure me that the same transient suppression is used on your downstream HW, then I'm just interested in getting back the correct O.S. read/write errors. We'll work on our hardware.
It looks like I need to check my driver's handling of read/write errors before I ask you to do anything.
Thanks for talking me through this. |
|
|
akidder
1519 Posts |
Posted - 29 Mar 2006 : 18:22:34
|
Thanks for the follow-up. The USB host port on the VGX uses the same tranzorbs for ESD protection as the USB function port does.
ESD is wiley, and can be tough to contain. If you think you're seeing a problem with the USB host ports, let us know how to reproduce it (preferably with a standard USB driver, like keyboard/mouse HID or storage classes), and we can look into it.
Let us know how we can help. |
|
|
3963
85 Posts |
Posted - 30 Mar 2006 : 14:53:58
|
It's been a few years since I've looked at my USB HID driver. I instrumented it and it looks like it's working fine (it's been stable for a few years); the IOControl call just returns FALSE. A check of GetLastError right before I return FALSE in the IOControl function of the USB driver returns '0'. On the application side, GetLastError returns the error 87. This error 87 seems odd. I'm not using SetLastError in the USB driver for the actual USB error codes since they are #defined using the same numbers as the system errors.
As far as ESD, we have been able to get the ActiveSync to hang/drop using a 4KV contact probe, though it usually takes 10-15 pulses to the chassis of our product. We're still looking at the host ports (won't be able to get any info on error 87 about other devices). Initial tests indicate that a thumb drive plugged directly into the Type A socket can take the 4KV that the ActiveSync can't. We're going to string the thumb drive out on some ribbon cable in our box to see if this increases the susceptibility.
Our goal is to make sure that once our boards are ESD safe, the VGX won't limit us from meeting the standard specs. It's not clear that these tests will do that unless they have positive outcomes (i.e. is it the SanDisk drive's limitation or the VGX's limitation?). |
|
|
akidder
1519 Posts |
Posted - 30 Mar 2006 : 16:42:13
|
If you can give us step-by-step instructions about how to reproduce what you're seeing, we'll be glad to look it over. It might make sense for you to email rather than to post it all here. |
|
|
|
Topic |
|