At 2:08 PM -0700 4/29/01, Wang, Paul wrote:
>Thanks for your reply. What I am doing is to write a general bootloader for
>both WinCE and ARM Linux, and use either serial or USB as console channels.
>The bootloader is based on polling.
Ah. OK. Will you be putting this under GPL? I might like to use such
a thing for
diagnostics, software updates, and so forth...
>The EP0 FIFO can only send the first packet (8-Bytes) corresponding to
>standard device descriptor request.
>After the first packet has been sent (and ACK'ed, as OPR,IPR and SE are all
>not set for the next EP0 IRQ), the write count register doesn't change with
>the next writing of byte, so the sending process is hanged. Then the host
>tried to reset the UDC, and do the sending again, but still fail.
Typically, after the first 8 bytes the host will "short-circuit" the
transfer and start a new one immediately without getting the rest of
the descriptor, once it discovers the actual length. I can't remember if
this happens with a reset or early SE indication. I would think you
would see OPR or SE, however. (Or SST or reset.)
The UDC can "turn around" the FIFO underneath you, even without raising
OPR -- for example if there is a protocol error (or sometimes, it seems,
if it just feels like it!). That is why, if I remember correctly, I
enclosed the whole fifo writing nonsense in a timeout loop that would
bounce out and continue on the next IRQ.
As a general rule, it seemed like many sorts of changes would not
propagate to the UDC core until the current IRQ was serviced.
Do you have any sort of USB analyizer hardware (like a CATC?) -- it is
very hard to figure our what is going on without one.
> Is this a specific hardware or just a timing problem ?
Just timing and the usual crap that surrounds this ill-conceived
subsystem!
Good Luck.
-- Ward
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
