Isoch Read/Write with loopback (newbie)

I am developing a driver for ISP1582/1583 for very high speed
application ( ~200M). I build my driver based on isousb from WinDDK
2k3. My platform is WinXP Sp2.

Now, the PC recognizes my board, but when I try using the testing
application from isousb to read/write, it does not work. It seems that
the testing application from DDK uses the name PIPE04 and PIPE05
directly to open the handle to the pipe. Is there any other way to
overcome this problem ?

I tried using the simple way, which is open a handle to the device
using GUID with CreateFile(), then using ReadFile() and WriteFile()
but that fails as well, GetLastError() return 22 - ERROR_BAD_COMMAND
[The device does not recognize the command.]

I will have to write a loopback mode application as well. The loopback
will only depend on user-mode application. Am I right ?

Pls enlighten me on this part. Thanks a lot !

Tim
Wed Mar 16 01:04:25 CST 2005

ngdong@gmail.com (dongnh) wrote:
>
>I am developing a driver for ISP1582/1583 for very high speed
>application ( ~200M). I build my driver based on isousb from WinDDK
>2k3. My platform is WinXP Sp2.

You mean 200 megabits per second? That is (just) beyond the maximum data
rate for an isochronous pipe on USB 2.0. The maximum is 24 MB/s, which is
192 Mbps.

>Now, the PC recognizes my board, but when I try using the testing
>application from isousb to read/write, it does not work. It seems that
>the testing application from DDK uses the name PIPE04 and PIPE05
>directly to open the handle to the pipe. Is there any other way to
>overcome this problem ?

What problem? If your device uses different pipe numbers, just change the
test application.

>I tried using the simple way, which is open a handle to the device
>using GUID with CreateFile(), then using ReadFile() and WriteFile()
>but that fails as well, GetLastError() return 22 - ERROR_BAD_COMMAND
>[The device does not recognize the command.]

Yes, you need to tell the driver which pipe to read from or write to. The
isousb sample doesn't support reading or writing to the base device.

>I will have to write a loopback mode application as well. The loopback
>will only depend on user-mode application. Am I right ?

The driver should be able to handle it. However, I seriously doubt you
will be able to sustain 48 MB/s of iso traffic.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

ngdong
Wed Mar 16 20:34:15 CST 2005

Tim Roberts <timr@probo.com> wrote in message news:<uulf31hbc6utgsuqaodidv6bppcvul6v5c@4ax.com>...
> ngdong@gmail.com (dongnh) wrote:
> >
> >Now, the PC recognizes my board, but when I try using the testing
> >application from isousb to read/write, it does not work. It seems that
> >the testing application from DDK uses the name PIPE04 and PIPE05
> >directly to open the handle to the pipe. Is there any other way to
> >overcome this problem ?
>
> What problem? If your device uses different pipe numbers, just change the
> test application.
>

Hi,

I have checked the firmware and found that they specified the
endpoints the same with WinDDK pipe number

void Init_Endpoint(void)
{
//check if device in full speed state
if(Kernel_Flag.BITS.HS_FS_State == FULL_SPEED)
{

//Bulk Out MaxPacketSize Endpoint

D14_Cntrl_Reg.D14_ENDPT_INDEX = 4;
D14_Cntrl_Reg.D14_ENDPT_MAXPKTSIZE.VALUE = 0x4000;

//Bulk In MaxPacketSize Endpoint

D14_Cntrl_Reg.D14_ENDPT_INDEX = 5;
D14_Cntrl_Reg.D14_ENDPT_MAXPKTSIZE.VALUE = 0x4000;


//Bulk Out Endpoint Type

D14_Cntrl_Reg.D14_ENDPT_INDEX = 4;
D14_Cntrl_Reg.D14_ENDPT_TYPE.VALUE = 0x1600;


//Bulk In Endpoint Type

D14_Cntrl_Reg.D14_ENDPT_INDEX = 5;
D14_Cntrl_Reg.D14_ENDPT_TYPE.VALUE = 0x1600;

//enable FIFO for two endpoints here



}

//check if device in high speed
if(Kernel_Flag.BITS.HS_FS_State == HIGH_SPEED)
{

//Bulk Out MaxPacketSize Endpoint

D14_Cntrl_Reg.D14_ENDPT_INDEX = 4;
D14_Cntrl_Reg.D14_ENDPT_MAXPKTSIZE.VALUE = 0x0002;

//Bulk In MaxPacketSize Endpoint

D14_Cntrl_Reg.D14_ENDPT_INDEX = 5;
D14_Cntrl_Reg.D14_ENDPT_MAXPKTSIZE.VALUE = 0x0002;


//Bulk Out Endpoint Type

D14_Cntrl_Reg.D14_ENDPT_INDEX = 4;
D14_Cntrl_Reg.D14_ENDPT_TYPE.VALUE = 0x1600;


//Bulk In Endpoint Type

D14_Cntrl_Reg.D14_ENDPT_INDEX = 5;
D14_Cntrl_Reg.D14_ENDPT_TYPE.VALUE = 0x1600;

//enable FIFO for two endpoints here


}

//set to DMA endpoint 1
//set to Endpoint Index to 2
//this is to prevent the endpoint index pointing to the same
endpoint
D14_Cntrl_Reg.D14_DMA_ENDPOINT = 2;
D14_Cntrl_Reg.D14_ENDPT_INDEX = 4;

//enable device and reset the device address
D14_Cntrl_Reg.D14_ADDRESS.VALUE = 0x80;

}


Using USBView, I see that there are only 2 bulk endpoints, 2 int
endpoints and device speed is high, but using rwiso from DDK, 2
interfaces, interface # 0 has 2 int endpoints and 2 bulk endpoints,
interface # 1 have 2 int endpoints, 2 bulk endpoints and 2 isoch
endpoints with PIPE num = 04 and 05 respectively.

Even I use the Pipe04 and pipe05, the app still does not work. Do you
have any idea about the possible reason ?

Tim
Thu Mar 17 21:57:38 CST 2005

ngdong@gmail.com (dongnh) wrote:
>
>I have checked the firmware and found that they specified the
>endpoints the same with WinDDK pipe number
>
>void Init_Endpoint(void)
>{
> //check if device in full speed state
> if(Kernel_Flag.BITS.HS_FS_State == FULL_SPEED)
> {
>
> //Bulk Out MaxPacketSize Endpoint
>
> D14_Cntrl_Reg.D14_ENDPT_INDEX = 4;
> D14_Cntrl_Reg.D14_ENDPT_MAXPKTSIZE.VALUE = 0x4000;
>
> //Bulk In MaxPacketSize Endpoint
>
> D14_Cntrl_Reg.D14_ENDPT_INDEX = 5;
> D14_Cntrl_Reg.D14_ENDPT_MAXPKTSIZE.VALUE = 0x4000;
>
> //Bulk Out Endpoint Type
>
> D14_Cntrl_Reg.D14_ENDPT_INDEX = 4;
> D14_Cntrl_Reg.D14_ENDPT_TYPE.VALUE = 0x1600;
>
> //Bulk In Endpoint Type
>
> D14_Cntrl_Reg.D14_ENDPT_INDEX = 5;
> D14_Cntrl_Reg.D14_ENDPT_TYPE.VALUE = 0x1600;
>
> //enable FIFO for two endpoints here

Well, this says that endpoints 4 and 5 on your device are bulk endpoints.
Why do you believe they should be isochronous?

>Using USBView, I see that there are only 2 bulk endpoints, 2 int
>endpoints and device speed is high, but using rwiso from DDK, 2
>interfaces, interface # 0 has 2 int endpoints and 2 bulk endpoints,
>interface # 1 have 2 int endpoints, 2 bulk endpoints and 2 isoch
>endpoints with PIPE num = 04 and 05 respectively.
>
>Even I use the Pipe04 and pipe05, the app still does not work. Do you
>have any idea about the possible reason ?

Have you selected interface #1? The default is #0.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

ngdong
Fri Mar 18 04:09:44 CST 2005

Tim Roberts <timr@probo.com> wrote in message news:<hakk31p8tp3hqadmj4h7uaem0rb854k7ot@4ax.com>...
> Well, this says that endpoints 4 and 5 on your device are bulk endpoints.
> Why do you believe they should be isochronous?

In high speed, the endpoints for transfering should be isoc endpoints,
am I right ?
>
> >Using USBView, I see that there are only 2 bulk endpoints, 2 int
> >endpoints and device speed is high, but using rwiso from DDK, 2
> >interfaces, interface # 0 has 2 int endpoints and 2 bulk endpoints,
> >interface # 1 have 2 int endpoints, 2 bulk endpoints and 2 isoch
> >endpoints with PIPE num = 04 and 05 respectively.
> >
> >Even I use the Pipe04 and pipe05, the app still does not work. Do you
> >have any idea about the possible reason ?
>
> Have you selected interface #1? The default is #0.

Yes, I noticed this yesterday and I have selected the alternate
setting. It works, thanks anyway!

Using the sample from MS DDK is not enough anyway, I am editting them
to suit my need. I can perfrom writing but can't perform reading or
dump data to compare, strange

Tim
Sat Mar 19 21:49:16 CST 2005

ngdong@gmail.com (dongnh) wrote:

>Tim Roberts <timr@probo.com> wrote in message news:<hakk31p8tp3hqadmj4h7uaem0rb854k7ot@4ax.com>...
>> Well, this says that endpoints 4 and 5 on your device are bulk endpoints.
>> Why do you believe they should be isochronous?
>
>In high speed, the endpoints for transfering should be isoc endpoints,
>am I right ?

I don't know what that sentence means. The endpoints are whatever the
descriptors say they are. If the endpoints are bulk, as your descriptor
set seemed to show, then you need to use bulk transfers.

>Using the sample from MS DDK is not enough anyway, I am editting them
>to suit my need. I can perfrom writing but can't perform reading or
>dump data to compare, strange

Now, you know that you have to read from a different pipe than you write
to, yes?
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

ngdong
Tue Mar 22 02:48:37 CST 2005

Tim Roberts <timr@probo.com> wrote in message news:<79sp31tchsg974siib59goo0t3ildkg26t@4ax.com>...
> ngdong@gmail.com (dongnh) wrote:
>
> >Tim Roberts <timr@probo.com> wrote in message news:<hakk31p8tp3hqadmj4h7uaem0rb854k7ot@4ax.com>...
> >
> >Using the sample from MS DDK is not enough anyway, I am editting them
> >to suit my need. I can perfrom writing but can't perform reading or
> >dump data to compare, strange
>
> Now, you know that you have to read from a different pipe than you write
> to, yes?

Hi Tim,

The problem is that the default interface does not contain the iso
endpoints, so it is stored in the alternate setting interface. When I
set the interface to alternate setting, the application can now
recognize the isoch read-pipe and isoch write-pipe. The fact that ISP
device contains one interface with an alternate setting depends on the
firmware, am I right ?

Now, I can perform write, but when I send IRP/URB for read, it failed
with error status C0000001. Do you know what does this mean and how to
correct it ?

Thanks a lot!

Tim
Wed Mar 23 22:31:23 CST 2005

ngdong@gmail.com (dongnh) wrote:
>
>The problem is that the default interface does not contain the iso
>endpoints, so it is stored in the alternate setting interface. When I
>set the interface to alternate setting, the application can now
>recognize the isoch read-pipe and isoch write-pipe. The fact that ISP
>device contains one interface with an alternate setting depends on the
>firmware, am I right ?

Yes. Well, it depends on the descriptors, which are usually managed by the
firmware.

>Now, I can perform write, but when I send IRP/URB for read, it failed
>with error status C0000001. Do you know what does this mean and how to
>correct it ?

You're sure you are sending the read URB to the iso input pipe, and not the
iso input pipe? Remember that pipes are one direction only.

Where do you get the C0000001? As an NTSTATUS, it means
STATUS_UNSUCCESSFUL. Very generic. As a USB error, it means
USBD_STATUS_CRC, a CRC error.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc