Ports and Interfaces > USB
usb interruptions, I think?
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.
--- Quote ---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.
--- End quote ---
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 != 8) /* 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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version