Strange USB behavior regarding BlockSize and DataSize

[mbergmann]

Hi,

I'm working on an USB Device Mass Storage driver for my own iMX233 Board. The software is all done ourselfe. No Linux or other BSP.

Currently I've problems answering READ-10 Command Transports.

If I set the wMaxPacketSize to 512 Byte I can send data up to 768 bytes. With this data size in the dTD I get the USB interrupt on complete after sending the data. But if I try to send more than 768 Bytes with one dTD I can see the first 512 Bytes in one IN txn packet on the bus, but other packages/the rest of the data is missing. Thus I do not get any interrupt. Furthermore the status:Active bit in the dTD is not cleared and no other status bit is set. It seems that the cell is hanging after the first package.

If I set the wMaxPacketSize to 256 or below I'm able to transfer up to 2K of data via one dTD. If I try to send more the transfer hangs after 2K.

Is there something special with the iMX233 USB regarding and data size and wMaxPacketSize. The code I'm using is working fine on my STMP3650 board (nearly same USB Cell).

Any idea?

Thanks

Mike

Message was edited: made more concrete

[mbergmann]

How do i get access to SR1-1024050961?

For the branch you made for this discussion (https://community.freescale.com/thread/304494)

I get an "Access to this place or content is restricted"

[YixingKong]

That SR created by stephan.knecht@bones.ch with subject "Strange USB behavior regarding BlockSize and DataSize".

I copy the response in that SR below:

------------------------------------------------------------------------------------

I cannot really make much sense of it all.

The queue head indicates that the dTD is active and nothing has been transferred (total byte count is 0x800, active flag is set, no error flags.

The protocol log shows 1 512 byte packet was transferred and acknowledged, so byte count should have been reduced with 0x200.

If the ACK would not have been seen by the controller, then the byte count would not have been reduced, but the controller than re-transmit at the next IN, which does not happen either.

The controller responds with NAK after the first 512 bytes have been transferred, which means the endpoint is not primed. This does not make sense because the endpoint auto-primes once the transfer has started (i.e first packet is started).

So I think the software does not correctly handle adding/removing dTDs from the queue.

One strange thing is that the initial queue head has address 0x6320 as current dTD, which is the same address as the queue head that is being added. This can be an indication that the same qTD is re-used for consecutive transfers and that may lead to timing issues (race conditions) between controller and software.

I recommend to always use an new dTD and link it to next-dtd in the queue head when adding a qTD to an active queue.

Please refer to the USB driver in Platlib. The driver library has an example on how to manage dTDs on a queue head.

Also, the i.MX5x reference manuals have more details on how to manage device queue heads. Please refer to these for more details.

____________________________________________

[YixingKong]

This same issue is reported in SR1-1024050961 and it was solved.