This thread is inspired by 's, of course! Only those files related to USB that were actually updated after SP3 are mentioned here. None of these updates is known to cause any issues. This is a trimmed version of the 1st post: the table below lists only the non-superseded updates, all others were have been removed for easier reaference. Only those files related to USB that were actually updated after SP3 are mentioned here.

None of these updates is known to cause any issues.

Gary Kercheck Hoping to get some expert advice here, Have an embedded USB application running on a Cortex M4. Application uses full-speed USB and is based on a Freescale-provided CDC USB sample project. My bulk 'IN' endpoint is defined for 64 bytes. Embedded application is communicating with an XP-SP3 2.5GHZ Core2 Duo laptop using the usbser.sys device driver and a COM program. I'm also running a software USB analyzer (USBlyzer). I have come up to speed on USB about as much as I humanly can in a few week's time, including reading Jan Axelson's 'USB Complete', so I'd like to think I know mostly what is going on. Every millisecond, my embedded application needs to send to the host PC roughly 500 bytes in a single 'IN' transaction.

According to everything I read, I should be able to do this by sending a burst of eight 64 byte packets followed by a ZLP to terminate the transaction. So here's what's happening; the terminal application polls my device with an IN request using a 4096 byte buffer. This generates a 'token received' interrupt on my embedded device which I _immediately_ service by sending a burst of 8 consecutive packets followed by a ZLP. (I also made sure to wait for clear of the 'OWN' bit during this burst). Half these packets appear to be lost on the other end. The only way I can seem to get reliable transfer is if I send single packet per transaction and wait for the host PC to send the next 'IN' request before starting a new transaction.

Hello All, Under Windows XP, has anyone been able to use usbser.sys (for CDC), WITHOUT ANY DRIVER INSTALLATION? According to the USB standards document, if you. #E339 Add Service: Binary 'C: WINDOWS system32 DRIVERS usbser.sys' for service 'usbser' is not present. #E032 Error 0xe0000217: A service installation section in this INF is invalid. #E275 Error while installing services. Error 0xe0000217: A service installation section in this INF is invalid. #E122 Device install failed. Stellaris Virtual Serial Port -BSOD(XP-SP3. Windows XP 32 bit, SP3. Since the BSOD had a description of the usbser.sys file I tried to replace with another usbser.

This winds up killing my performance. Am I simply asking too much of the usbser.sys driver or am I missing something simple here? Tsuneo Chinzei >I'm able to get 192 bytes in a single DATA IN transaction. How many bytes are received by single transfer on USBlyzer log? P2p Addons Xbmc. If you see 192 bytes on USBlyzer, the device sends just 192 bytes (three 64-bytes transactions and ZLP).

If this is result of 512 bytes transfer, your firmware still have trouble for 512 bytes transfer. If you see 512 bytes on USBlyzer, but 192 bytes on PC application, - Increase IN buffer size of usbser.sys by SetupComm( dwOutQueue ) (Win32 API) or SerialPort.WriteBufferSize (.Net) OR - Your PC application reads just 192 bytes. >Am I running up against the bandwidth limit of usbser.sys for full-speed devices? As you said, usbser.sys requests 4 KBytes bulk IN request for every IN transfer to the host controller (HC). HC handles this request like other bulk transfers from other device driver. While this transfer is going on, there is no difference caused by PC device driver.

That is, you should be able to see 18 or 19 full-size (64 bytes) packets/frame transfer speed on idle bus. Gary Kercheck First of all, thank you for sharing your time and expertise. It is incredibly helpful to have someone who understand the gory details of USB to bounce this stuff off of. >If you see 192 bytes on USBlyzer, the device sends just 192 bytes (three 64-bytes transactions and ZLP). If this is result of 512 bytes transfer, your firmware still have trouble for 512 bytes transfer. I do indeed only see 192 bytes on USBlyzer.