I have hardware using the Cypress SX2 chipset. Using the EZUSB Control Panel supplied by Cypress, and this hardware, I can push the ISO TRANS button and get nice looking data from the device (it is landfill generated by the Hardware Dude who sits next to me).
So the hardware is working fine.
My goal now is to read/write iso from my own code. I have written a little applet that opens the device, resets the pipe,and sends down an ISO_READ ioctl. I wrote the code after painstakingly reverse engineering what the control panel app is doing through use of a third party software based USB packet sniffer and the Windows XP kernel debugger, WINDBG. I am quite certain I am doing the same things and in the same order as the control panel: open, reset pipe, iso read. I am also taking pains to set my crucial read variables to the same as in the control panel, viz:
const unsigned PACKETSIZE = 16;
const unsigned PACKETCOUNT = 128;
const unsigned PIPENUM = 3;
const unsigned BUFFERCOUNT = 2;
const unsigned FRAMESPERBUFFER = 8;
…
PUSBD_ISO_PACKET_DESCRIPTOR isoDesc;
IsoControl.PacketSize = PACKETSIZE;
IsoControl.PacketCount = PACKETCOUNT;
IsoControl.PipeNum = PIPENUM;
IsoControl.BufferCount = BUFFERCOUNT;
IsoControl.FramesPerBuffer = FRAMESPERBUFFER;
Moreover, when I issue the read, I can check the buffer size variable in the irp down in the driver. It is the same in my code as in the control panel code, 0xe00.
You may recall that when this IOCTL is called, the driver returns a buffer which contains data packets end-to-end in the first part (payload), and the last part is an array of headers containing status information about each packet. The driver also returns NT status, a USB status DWORD, and the length of the returned data, in addition to setting a LastError variable to be retrieved from GetLastError().
I am getting back ERROR_SUCCESS from DeviceIoControl(), a returned data length of 0, and a buffer that is not touched in it’s leading half, but which has an array of headers at the tail end. The headers all say that zero bytes of data were returned in the packet, and an error USB_BABBLE_DETECTED is returned for each(I noticed the control panel sometimes also returns this error, but always has data). The headers also contain offset information which appears to be correct.
But, no payload! Nothing but air.
I have followed this down to IoCallDriver() where it calls the USB bus driver. As far as I can see, the parameters are all fine going in - the packets for my code and the control panel call are all being set up in the same code path; the variables are all the same. But no dice.
I assume the cypress code is passing some value down at some point that is different from what I am using - a flag, a buffer size, G-d knows - but I am not able to figure out what it is. I have scoured my code and the structures being passed into the driver but as far as I can see we are passing exactly the same bits down to the same hardware through the same driver, but we are getting different results. I have also checked the PhysicalDeviceObject and StackDeviceObject to make sure the same bus driver is getting both calls. It is.
So, obviously I am missing a flag somewhere. I don’t have the source to the cypress app, and the apps for which I have source are not working.
Does anyone know what this could be? What is the missing variable?
Thanks very much.
Eric