Ports and Interfaces > USB

usb interruptions, I think?

(1/6) > >>

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.

Navigation

[0] Message Index

[#] Next page

Go to full version