Author Topic: WinUsb_ReadPipe returning ERROR_SEM_TIMEOUT  (Read 12656 times)

juliang

  • Member
  • ***
  • Posts: 13
WinUsb_ReadPipe returning ERROR_SEM_TIMEOUT
« on: March 16, 2011, 05:06:15 pm »
Hi,

I built a WinUSB driver, my driver works perfectly on Windows XP, but when running on Windows7 I got the error 121 when calling WinUsb_ReadPipe, by debugging my driver I notice that WinUsb_ReadPipe is returning the error code 121 but the buffer contains what it should contain, I it is reading from the pipe and putting the content on the buffer I passed but still the function is returning this error. I tried increasing the timeout time with WinUsb_SetPipePolicy function, but still I am getting the same error. Is there anything I need to configure on the pipe so the reading process does not fail?

Any input will be helpful.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research

juliang

  • Member
  • ***
  • Posts: 13
Re: WinUsb_ReadPipe returning ERROR_SEM_TIMEOUT
« Reply #2 on: March 22, 2011, 05:17:33 pm »
Hi Jan,

Thanks for your answer, I was able to solve the problem, I just needed to use the WinUSB_AbortPipe function when closing the device, it seems that a reading process was still running impeding to take a good reading next time I opened the device.

I have another issue, when I install my device, it is installed successfully; however, I can see on the device manager that my device keeps enumerating forever, any idea of why is my device doing that?

mdlayt

  • Member
  • ***
  • Posts: 40
Re: WinUsb_ReadPipe returning ERROR_SEM_TIMEOUT
« Reply #3 on: March 25, 2011, 08:00:37 pm »
I think you contradict yourself.  If it is installed successfully, it won't enumerate anymore (unless you have a tester running or something).

I would be quite surprised if you can communicate with it while this is happening.  Maybe it is something well after enumeration that is going wrong.

One scenario:  it works for a while, then crashes.  When it crashes it resets.  Then the microcontroller reset event causes it to disconnect itself from the bus.  So the whole scenario starts over.