USB DATA Frame Synchronization

I'm using interrupt endpoints to read data from my USB device. I appear to
be having some problems related to maintaining the correct DATA0/DATA1 data
frame synchronization between my device and the USBD. I've read the
documentation and still am confused.
So, my questions are:
When, if ever, does the USBD reset the data frame for a particular
endpoint back to DATA0?
Can I (and is it ever wise to) force the USBD to reset an endpoint's
data frame to DATA0?

Thanks in advance for the help,
Dennis

Tim
Thu Oct 14 01:16:22 CDT 2004

"Dennis Burns" <dburns@rtessentials.com> wrote:
>
>I'm using interrupt endpoints to read data from my USB device. I appear to
>be having some problems related to maintaining the correct DATA0/DATA1 data
>frame synchronization between my device and the USBD. I've read the
>documentation and still am confused.

DATA0/DATA1 confusion usually indicates hardware/firmware problems. There
is nothing you can do in software to help this. Do you have a protocol
analyzer, like a CATC? That may be your best plan.

>So, my questions are:
> When, if ever, does the USBD reset the data frame for a particular
>endpoint back to DATA0?
> Can I (and is it ever wise to) force the USBD to reset an endpoint's
>data frame to DATA0?

It's not possible. That's a low-level protocol issue.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

Dennis
Thu Oct 14 16:38:31 CDT 2004

Hello Tim,
Thanks for the help.
I do have a protocol analyzer and I use it quite often.
I'm just trying it understand the ground-rules for interrupt transfers.
Rules for control transfers are pretty clear.
For interrupt transfers, it seems that no matter how many URBs I pass down
the stack, and no matter how many bytes I request, that the DATA0/1
alternation will always be followed on the USB bus. But then I'm just trying
to make sure.
My device is pretty bursty. I can have long periods of no data, or several
bytes, or a thousand bytes.
If for some reason I have to reset the endpoint (and I don't know if I'll
ever need to do this), then how do I make sure I maintain synchronization?

Best Regards,
Dennis

"Tim Roberts" <timr@probo.com> wrote in message
news:6a6sm0tbs27v8mokv2m41pt407q78loev7@4ax.com...
> "Dennis Burns" <dburns@rtessentials.com> wrote:
>>
>>I'm using interrupt endpoints to read data from my USB device. I appear to
>>be having some problems related to maintaining the correct DATA0/DATA1
>>data
>>frame synchronization between my device and the USBD. I've read the
>>documentation and still am confused.
>
> DATA0/DATA1 confusion usually indicates hardware/firmware problems. There
> is nothing you can do in software to help this. Do you have a protocol
> analyzer, like a CATC? That may be your best plan.
>
>>So, my questions are:
>> When, if ever, does the USBD reset the data frame for a particular
>>endpoint back to DATA0?
>> Can I (and is it ever wise to) force the USBD to reset an endpoint's
>>data frame to DATA0?
>
> It's not possible. That's a low-level protocol issue.
> --
> - Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc

Tim
Sat Oct 16 12:17:26 CDT 2004

"Dennis Burns" <dburns@rtessentials.com> wrote:
>
>I do have a protocol analyzer and I use it quite often.

I wish I did. Sigh. Most of my clients do, but I haven't been able to
justify the cost for our small company.

>I'm just trying it understand the ground-rules for interrupt transfers.
>Rules for control transfers are pretty clear.
>For interrupt transfers, it seems that no matter how many URBs I pass down
>the stack, and no matter how many bytes I request, that the DATA0/1
>alternation will always be followed on the USB bus. But then I'm just trying
>to make sure.

Right. As a driver writer, it's not your problem. It's all handled below
you.

>My device is pretty bursty. I can have long periods of no data, or several
>bytes, or a thousand bytes.

Then may I ask why you chose an interrupt pipe, instead of a bulk pipe?
Bulk pipes are perfect for bursty data. Interrupt pipes are designed for
low-volume data at regular intervals. They're basically low-volume
isochronous pipes. You didn't get sucked in by the myth that "interrupt"
pipes somehow "interrupt" the processor, did you?

>If for some reason I have to reset the endpoint (and I don't know if I'll
>ever need to do this), then how do I make sure I maintain synchronization?

YOU (the driver writer) don't have to. USBD will track it on the host end,
and your device's firmware tracks it on the device end. It's all
automatic.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

Marc
Sat Oct 16 13:04:51 CDT 2004

Actually, they are low volume Bulk Pipes. The interface at both ends is
identical to Bulk. Transfer on the bus is identical. They both have error
detection, Iso does not.

Marc Reinig
System Solutions

"Tim Roberts" <timr@probo.com> wrote in message
news:ril2n0pkpl88dht1j7uig1locncjb12nu5@4ax.com...
> "Dennis Burns" <dburns@rtessentials.com> wrote:
> Then may I ask why you chose an interrupt pipe, instead of a bulk pipe?
> Bulk pipes are perfect for bursty data. Interrupt pipes are designed for
> low-volume data at regular intervals. They're basically low-volume
> isochronous pipes. You didn't get sucked in by the myth that "interrupt"
> pipes somehow "interrupt" the processor, did you?