usb interruptions, I think?

[ulao]

Can anyone tell me what this means? Every once in a while my usb device stops and this is shown in my scanner.

The longer I extend my control data transfer lengthen (i.e 64 instead of 16), the more often this occurs.

[Jan Axelson]

It appears to be responding to the fact that a Get Report request failed to complete. So you need to figure out why. Is the endpoint:

sending ACK in the Setup stage?

sending data in the Data stage?

sending ACK in the Status stage?

[ulao]

I guess I was curios more so of the orange highlight. But after a reboot you are right, it's the control transfer ding. I know why but I just can't find the solution. I have a catch 22 chase here. If I disable the IRQ for my USB when I do my sensitive read, the control transfer seems to trip up because the KA single was not there. If I in-turn make sure that the sensitive code runs just after a USB poll and not disable interrupts, the control transfer seems to step on the USB poll read.

So what I did was in my USB code I sync the sensitive code after the 8ms USB poll.
In my software I get the USB poll event (16 bytes so two USB polls 1.1 (8 bytes max), and immediately do the controller transfer.
  - based on theory it should be after the second poll but shows after the first, not a big deal but confusing.
I also no longer disable interrupts around my sensitive code. Since it is in-sync and not over stepping my KA signals, all should be fine.

See image for details.
blue my control transfer
red my USB poll (every 8 ms)
green my sensitive code

So in theory it all fits in to place, but some how every once in a while I get the controller transfer to fail or currupt USB poll data. If I remove the disable IRQ's the USB poll data (every 8 ms) is corrupt if I leave the disabled IRQ in place the controller transfer trips up.. To make matter worse, I tried to capture this on my analyzer and would you belie it... no errors. As a matter a fact, I can run my scope for 20 seconds and while running, no issue.  This is no joke and driving my nuts.  It's almost like the usb needs additional Resistance on the wire but this hardware has ran the test of time.

[ulao]

Also wanted to add this and I'm not sure this is normal, its like it plays hell syncing. It is very long, lets see if it shows up on here.
Yeah its good just scroll.

It does eventually sync and sends all the correct data. This seems to take about 4 ms.

[Jan Axelson]

Most critical is to be sure to set up the endpoint to ACK all Setup packets, return NAK or data in the Data stage (control IN transfer), and return NAK or ACK in the Status stage.

Except for Setup packets, it's OK for the endpoint to NAK for a while until it's ready, but the endpoint must return _something_ when the host communicates for it no matter what is going on with other sensitive code, etc.

[ulao]

Ok, maybe there is something I'm missing. I attached one more image to show what is going on here. And now I see that the issue is where the control is taking too long to complete.

So based on your reply.

Most critical is to be sure to set up the endpoint to ACK all Setup packets, return NAK or data in the Data stage (control IN transfer), and return NAK or ACK in the Status stage.

I belie I follow you here.

I currently only have 3 paths

set reports return USB_NO_MSG - used to tell the driver a set report is greater then 8, so that it calls my usbFunctionWrite function.
get reports return the size -   In all cases it should match the input length. So I normally just returns rq->wLength.word;
neither, not sure. I currently return rq->wLength.word; Maybe I need to return a -1 or 0? I think the driver handles all NAK and ACK.

[ulao]

yeah looks like the only thing I can return from usbFunctionSetup  is a length

the driver does the NAK

    if(usbRxToken == (uchar)USBPID_SETUP){
        if(len !=     /* Setup size must be always 8 bytes. Ignore otherwise. */
            return;
        usbMsgLen_t replyLen;
        usbTxBuf[0] = USBPID_DATA0;         /* initialize data toggling */
        usbTxLen = USBPID_NAK;              /* abort pending transmit */
        usbMsgFlags = 0;
        uchar type = rq->bmRequestType & USBRQ_TYPE_MASK;
        if(type != USBRQ_TYPE_STANDARD){    /* standard requests are handled by driver */
            replyLen = usbFunctionSetup(data);
        }else{
            replyLen = usbDriverSetup(rq);
        }

I'm new to the usb signal, can anyone tell me if the driver is failing to NAK/ACK? This 2-8ms for sending a control transfer has to be wrong.

[ulao]

Ok I caught it in action. It is doing exactly what I thought it was doing. The control transfer just goes on for ever.

The usb driver and software are not working together. For some reason in this case 2 seconds. I can not image the driver woudl not send it NAK/ACK for that amount of time but... whatever this "syncing" is looking for is just not there. I don't know enough about the usb signal to know what it is looking for and Jan has pointed out the importance of  NAK/ACK. Though 2 seconds? Something clearly is wrong here. Controller transfers should only take a few ms, not 4 and certainly not 2 seconds.

Can anyone shed light on what "should" go on here.

[Jan Axelson]

The driver doesn't send ACK/NAK; you need to be sure the endpoint is configured to return ACK, NAK, or data immediately, as appropriate, for every transaction. How to do that varies with the controller chip architecture. Check the data sheet.

A control transfer can take as long as 5 seconds to complete, but the individual transactions must complete quickly, no time for firmware intervention.

[ulao]

Oh sorry, this is a software based USB (vusb), Bit banging but really well know, Of course there is the possibility that this is a downfall of this 1.1 driver but I tend to doubt that.  I have checked the code over well and there are no holes, it always returns something. No calculation need to be done as the data is already ready.

--------update------------
Ok I see what is causing the ACK/NAK to fail. There is some ASM code getting frozen causing the USB to stall. This was easy to band-aid but the real issue needs to be dealt with.

A quick guess is that the code is getting stuck. It seem to get stuck because the control transfer is running during this ASM. At the moment I can't quite understand why unless this control transfer syncing is firing interrupts? <pretty sure this is the clients responsibility? see note below>  This ASM code is very tight, 100ns off and it will trip up. So I really need to know how the hardware level of the usb control transfer works. '

added an image to show bad(right)/good(left).

Things that would help to know.
What is the syncing looking for?
Can a controller transfer be bulk or interrupt?
If bulk is possible will it only send once ever 8 ms?
Can one put a time out on the transfer so it does not try longer then 8 ms.
Is there a write up, book or any info that explains this at signal level.

So interrupts... I see an 8 ms signal I think comes from the OS AKA USB poll rate (should be 10 ms but windows and most operating system use 8 for 1.1) and a 900us signal I think comes from the device (hey I'm ready sending me something). A control transfer I would guess dose not sending a signal of any kind. It just starts the transfer waiting for something, hence the up to 5 seconds. Looks like it connects on one of the 900us signals. I think is is called bulk transfers. Timing can be loose but at times faster then the interrupt transfer. Or at least how I understand it.

As you can see by the image I place the sensitive code in side the 900 us signals. For some unknown reason to me, the control transfer over stepping this sensitive code is causing my problem. I just need to figure out why. I would think the design is to do nothing with the control transfer until the interrupt fires. It's not like the chip is multi threaded? So AFAICT that code is just going over the wire and not disturbing the firmware. If  I'm wrong, what takes place here?

[Jan Axelson]

I don't know what you mean by "a software based USB (vusb)."

USB defines four types of transfers: control, bulk, interrupt, and isochronous.

A control transfer is not a bulk transfer or an interrupt transfer; it is a control transfer.

[ulao]

https://www.obdev.at/products/vusb/index.html
its a firmware only usb driver (no hardware).

Ok, I can read up on the 4 types and see if this helps. Do all feature reports need to be control transfers>

[ulao]

Ok a bit more understanding and investigation and now I'm closer to the problem. I don't think this is USB related and I'm leaning more on a HIDAPI bug. Tough, what are your thoughts? Am I thinking right?

What is going on here is the control transfer is running overtime and stepping on a interrupt transfer. From what I have read the interrupt transfer is of a higher importance. So during the the control transfer and in the case of a collision, should the control transfer not surrender?

In my case this is not happening, the control transfer is continuing to run and the interrupt transfer is surrendering. In this case the data from the interrupt transfer is corrupt.

I think this guy has my same issue
https://stackoverflow.com/questions/20980984/usb-2-0-frame-sof-collision

[Jan Axelson]

Interrupt transfers have guaranteed maximum latency (time between transactions).

The host reserves a portion of the bus bandwidth for control transfers.

The host controller manages the bandwidth, scheduling interrupt transfers according to the maximum latency requested in the endpoint descriptor and scheduling control transfers in the remaining bandwidth. These are the only two transfer types for low-speed devices.  The firmware driver you referenced is low speed only.

Because the host controls all bus traffic, there are no "collisions."

Yes, Feature reports must use control transfers.

[ulao]

this was very helpful info. Would you agree that this (captured on low speed). is not possible? Based on the info you mentioned (and I would have no place to argue)  it is not possible to get a collision from low speed. low speed or not, I read you should never get collisions from these types of transfers.  Though here you have it happening. I simply must be explaining something wrong or misunderstanding.

This snap shows the control transfer overstepping the interrupt transfer.

Could it be that I somehow have my endpoints messed up?

Code: [Select]


Endpoint Descriptor 81 1 In, Interrupt, 8 ms
Offset Field Size Value Description
0 bLength 1 07h 
1 bDescriptorType 1 05h Endpoint
2 bEndpointAddress 1 81h 1 In
3 bmAttributes 1 03h Interrupt
 1..0: Transfer Type  ......11  Interrupt
 7..2: Reserved  000000..   
4 wMaxPacketSize 2 0008h 8 bytes
6 bInterval 1 08h 8 ms

Endpoint Descriptor 01 1 Out, Interrupt, 8 ms
Offset Field Size Value Description
0 bLength 1 07h 
1 bDescriptorType 1 05h Endpoint
2 bEndpointAddress 1 01h 1 Out
3 bmAttributes 1 03h Interrupt
 1..0: Transfer Type  ......11  Interrupt ---(I tried changing to a 0 and it didn't help.) ---
 7..2: Reserved  000000..   
4 wMaxPacketSize 2 0008h 8 bytes
6 bInterval 1 08h 8 ms

};
My interrupt transfers are on Endpoint 1 as I can see on the wire (shown in image).
and my controls are on Endpoint 0.

seem backwards to how I set it up, maybe EP are counted backwards?