(Upstream). Also implemented read-only mass storage mode.
Todo:
- Test. Everything!!!
- Report write protect flag in SCSI "mode parameter header" (whatever
that is)
So it turns out the SCSI ReadCapacity10 command does not return the
device capacity. It returns the address of the last block, which is
(capacity - 1).
Also fixed Upstream's end-of-device sanity check.
Upstream's edge-detect interrupt that starts SPI transmission was not
firing. Sometimes. On some boards only. The cause was Downstream not
allowing enough time between edges for Upstream to catch the signal.
Also misc code tidyups.
It turns out that suspend support on the STM32 USB core is buggy as
heck. Host mode cannot resume after suspend, and device mode cannot
receive resume or send wakeup signalling.
I managed to fake resume support by keeping Downstream and our connected
device running at full power, and simulating a wakeup event to the host
by disconnecting/reconnecting Upstream from the host.
...Downstream was not always changing state correctly after closely
spaced interrupts.
Also improve flash-write-lockout function to avoid dependency on
optimisation level.
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 :)
- 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.
So apparently the STM32F401's SPI DMA is even more buggy than the 405's.
Worked around an intermittent stall/timeout by busy-waiting Upstream's
packet length transmission and reception, instead of DMA-ing it like the
packet body. Ugh...
Robert Fisk