It will sometimes NAK part-way through a multi-packet OUT URB. And what
it wants is for the host to resend beginning from the last even-numbered
packet. NOT the last packet it received, and NOT the beginning of that
URB.
It turned out we were getting a "device disconnected" interrupt while
waiting for the port to enable following reset. Simply ignoring the
disconnect interrupt allows everything to work! WTF...
Each USB transaction passed to the driver now consists of multiple
64-byte packets. 8 packets when receiving, 4 packets when transmitting.
The STM32 silicon bugs out when more than 4 packets are scheduled to
write at a time :(
Reads 1.0MB/sec, writes 967kB/sec, not CPU limited :)
Added timeout checks and retry functionality to control transaction
state machine. But some times the device just won't talk, so we flash
the fault LED slowly to give the user some clue about what happened.
- Unexpected second port-connected interrupt on cold boot with low-speed
device connected.
- Retry on failure to get device descriptor. (We still fail after three
attempts, but that is better than failing after the first one!)
Also changed eclipse project to use external builder.
some flash drives can take up to 2 seconds to write a single block.
Also, reverting the previous two commits because they didn't actually
help. Aughhhhhh...
NOTE: Downstream's full-speed host controller is flakey when connecting
to low-speed devices. One mouse enumerates on only 50% of connection
events, while another mouse enumerates on 90% of connections. Grrr.
interacts with SPI.
It elevates to USB_OTG priority to avoid preemption by SPI, DMA, or USB
interrupts thus avoiding synchronisation issues between USB host stack
and SPI interface.
Also minor improvements to Downstream error handling.
Robert Fisk