usb interruptions, I think?

[Jan Axelson]

Endpoint 0 is always the default endpoint for control transfers.

I don't know what you mean by "overstepping the interrupt transfer," couldn't make sense of the attached image.

Be aware that a control transfer has two or three stages that each require one or more transactions. So the host might schedule interrupt transactions interwoven with the stages of a control transfer, for example:

EP0 Setup stage ACKed
EP1 interrupt transaction
EP0 Data stage NAKed
EP1 interrupt transaction
EPO Data stage ACKed
EP1 Status stages ACKed

[ulao]

I see the stages of the control but the main USB poll is missing when the control transfer fires at the same time.

Image explained.
If you open up the image in a new window and maximize it you will see the image is broken in to 4 parts. The top most image is a zoomed out look. You can very clearly see the USB polls on channel 2.  Every time (8ms) the USB host gets data from the device (interrupt transfer) that spike appears. at +50 ms it appears to be hidden in the blob (the control transfer).

The next image is a blow up of the red square selection, (part of the control transfer) for reference (where the poll should have been). 

Next, a zoom in of this section (again the red square outline). Showing there is absolutely no interrupt transfer taking place. All that can be seen is a control transfer.

The last image is what an interrupt transfer would look like.

What I'm trying to point out in the images here, is that the control transfer took place where the interrupt transfer should have been. I'm trying to figure out how that is even possible.

[Jan Axelson]

Why do you think the host is using interrupt transfers? It sounds like the host using control transfers only.

[ulao]

This is a gamepad usb device that uses a normal poll. In my code I use a
while (!usbInterruptIsReady()) usbPoll(); usbSetInterrupt( reportBuffer, ;
this needs to happen ever 8 ms, or the device can not work right. The control transfer is cause this very issue. Somehow it prevents this poll (not very often) when it over steps.

[Jan Axelson]

The host is obligated to attempt an interrupt transfer with a low-speed device every 10 ms (or longer as specified in the endpont descriptor). If the host is neglecting to do this, it's a bug in the host controller.

In fact, to be compliant, you should change bInterval to 10 (0ah) though I doubt that this is source of any problem.

However, the host may schedule a transfer attempt at more frequent intervals, such as 8 ms.

Of course, the host will not receive any interrupt data unless the device has it ready to send on receiving an IN token packet.

[ulao]

This does make sense to me but correct me if I'm wrong? The host in this case is windows 7, is the OS not the host? I could try a 10ms poll but from what I have seen windows ignores that and does 8 anyways. I tend to doubt windows has a bug that has gone unseen.

If I can rule out a host bug, the only possible issue then, is that the device is, as you said, not ready. My only guess is during the transfer of the control data the device is incapable of replying to the interrupt transfer. I guess ill try to debug that.

[Bret]

I'm not sure if this will help or not, but here goes.  Remember that the USB bus is a master/slave architecture.  The Host is the master, and the device (in this case, your device) is the slave.  You must do what the host tells you to do, when the host tells you to do it.  Period.

As Jan eluded to earlier, when the host sends you a packet requesting something, you must respond immediately with something, even if it is simply a NAK.  The host will only send one packet at a time down the bus.  The packet could be an interrupt packet, one of the control packets (control transactions always involve more than one packet), or something else.  The host cannot send you a control packet and an interrupt packet at the same time -- it is a serial bus (it only sends one bit at a time).

Also, exactly when you are sent each packet is not consistent.  A packet can be sent to you any time within a frame (frames are 1 ms long in USB 1).  You can get it at the beginning, middle, or end of the frame, and you have to respond appropriately and quickly no matter what.  The host decides exactly which packets get sent when inside each frame.

[ulao]

ret is does help but there is one issue.

The host cannot send you a control packet and an interrupt packet at the same time -- it is a serial bus (it only sends one bit at a time).

I know studding screen shots is no fun... but if you take a closer look at mine you will see this issue.
channel 4 are my frames
channel 2 are my data (small data is the interrupt longer the control transfer)
channel 3 is just debug
Based on our collective knowledge, we all agree, it can not happen. The Host can not send a control transfer if the interrupt transfer is scheduled. It "seems" to be doing just that.  If the host knows it has a interrupt scheduled, why would it send the control transfer?

Outside this issue yes, this does help. I didn't know why the 1 ms interrupts were on the line. So this is the frames. The more I learn the better I will be at figuring this out.

Correct me if I'm wrong, but the host is software, the USB OS driver, yes? My software tells the host to send a control transfer and the host should know better then to send it out when an interrupt transfer is scheduled.

[Bret]

Correct me if I'm wrong, but the host is software, the USB OS driver, yes?

No, that's not right.  It's a combination of hardware and software.

The software places transactions in memory that it wants the hardware to perform.  The hardware reads those transactions from memory and sends them across the bus in an autonomous fashion, and then the hardware places the results of the transaction into memory (and generates hardware interrupts if the software wants it to) to notify the software of what happened.  The software builds a queue of transactions it wants the hardware to perform.  The hardware starts at the top of the queue, sends the packet it needs to out across the bus, waits for the device to send a return packet across the bus, and then tells the software what the device sent back (using memory and hardware interrupts).  Then, the hardware goes to the next transaction in the queue and does the same thing again.

Exactly what happens behind the scenes in memory between the host hardware and software is very complicated, and even varies significantly depending on the type of host it is (UHCI, OHCI, EHCI, xHCI, WHCI, ...).  There is also a priority mechanism inherent to the queuing process to make sure isochronous and interrupt transactions get precedence over control and bulk transactions.   But the basic concept of the software queuing transactions in memory and the hardware issuing the transactions one at a time across the bus doesn't change.

[ulao]

So my software does need to "not" send two transfer at once? This was clearly my misunderstanding. I figure the HID API I'm using was taking care of that. I'll follow up though angle. Thx.

[Jan Axelson]

Control transfers have multiple stages. The host can schedule interrupt transfers between the stages or between transactions within a stage where that applies.

[ulao]

One more question here. Per the previous discussion, as I mentioned, I have both interrupts and control transfers. In my software I control the 'control' transfers. Though the interrupt transfers happen all the time. By that I mean whenever the OS is up and running. These transfers start the minute I pug in my device. So I'm guessing the HID/game controller driver handles these? More to the point, can I stop/pause this?

[Jan Axelson]

The host driver schedules periodic transfer attempts for interrupt IN endpoints. The device endpoint needs to be set up to NAK all IN token packets unless there is data to send.

[ulao]

Is there a way to pause or start/stop this from software?

[Jan Axelson]

A low-level filter driver might be able, but not application software.