This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: AT91 USB driver sending empty packet


I guess the problem in my case is that the host is reading multiple
sectors of the mass storage device in a single READ and I am sending
sector by sector so the USB driver is inserting the empty packet in
between sectors since it thinks this is the end of the transfer (and the
sector size is a multiple of the endpoint buffer size). 

I'll have to find out what is the maximum data transfer size expected
and see if I can allocate such a large buffer in the MSD package.

Thanks both of you for helping.

Christophe 

	
-----Original Message-----
From: Frank Pagliughi [mailto:fpagliughi@mindspring.com] 
Sent: 29. juni 2010 23:20
To: Christophe Coutand
Cc: Chris Holgate; ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] AT91 USB driver sending empty packet

Actually the behavior for Bulk Transfers is defined in section 5.8.3 of 
the USB 2.0 standard, entitled, "Bulk Transfer Packet Size Constraints."

It states:

    When a bulk IRP involves more data than can fit in one maximum-sized
    data payload, all data payloads are required to be maximum size
    except for the last data payload, which will
    contain the remaining data. A bulk transfer is complete when the
    endpoint does one of the following:
    * Has transferred exactly the amount of data expected
    * Transfers a packet with a payload size less than wMaxPacketSize or
    transfers a zero-length packet

So, technically, a higher level piece of code /could/ decide that all 
data was transferred, but it's usually difficult for a low-level driver 
to have this knowledge. All drivers I have ever seen just transfer a 
zero-length packet if the final data packet is the exact size of the 
endpoint.

Frank

Christophe Coutand wrote:
> Hi Chris,
>
> Thank you for clarifying that for me. I could not yet find any info
> about the expected behavior of the bulk storage class drivers to empty
> packet. I found that empty packet can be used in some specific cases
but
> nothing about termination of a regular data transfer phase. I think I
> will implement what you have suggested and post a patch. Sending empty
> packet should still be possible from the application layer therefore
> should be acceptable.
>
> Christophe 
>
>
> -----Original Message-----
> From: Chris Holgate [mailto:chris@zynaptic.com] 
> Sent: 28. juni 2010 23:44
> To: Christophe Coutand
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] AT91 USB driver sending empty packet
>
> Hi Christophe,
>
> Christophe Coutand wrote:
>
>   
>> The AT91 USB driver is sending an empty packet at the end of a data
>> transfer (transfer from device to host) if the last fragment of the
>> packet is exactly equal to the endpoint size. Is this part of the USB
>> specification? 
>>     
>
> The basic USB spec doesn't define this one way or another.  Whether or
> not bulk transfers use this kind of zero length packet termination
> depends on the class driver specification.  Typically, comms-style
class
> drivers will use zero length packet termination because it is not
> possible to know in advance how much data will be transferred for
> variable length packets, etc.
>
>   
>> In my case, this is triggering a reset from the host
>> (both Linux or Win). Not sending the empty packet fixes the problem.
>>     
> The
>   
>> transfer is 512 bytes sent in two USB data packet.
>>
>> As anyone experienced such an issue? 
>>     
>
> I'm not familiar with the bulk storage class drivers, but from what
> you're saying it sounds as though they do not use zero length packet
> termination.  With the STM32 USB driver I added a CDL option to turn
> zero length packet termination on and off for the entire USB device.
> This may not be the most flexible approach, but it should be adequate
> for most applications.
>
> Chris.
>
>   


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]