On Thu, 13 Mar 2014, David Mosberger wrote: > OK, I finally know where the problem is coming from! The MAX3421E > chip uses double-buffering. Specifically, it has two 64-byte send > FIFOs. You write up to 64 bytes to a send FIFO by repeatedly writing > to SPI register 2 (SNDFIFO). Then you tell the chip how many bytes > you just put in the FIFO by writing SPI register 7 (the > send-byte-count or SNDBC register). Writing SNDBC is supposed to > switch the FIFO to the USB-side so it can be transmitted on the USB > bus. > > Unfortunately, it seems that under certain circumstances, writing the > SNDBC fails to properly switch the FIFOs and we end up sending data to > the USB bus from the wrong FIFO. > > In the USB mass-storage error situation we're seeing, the driver was > trying to send a 31-byte "USBC" command and we see that command coming > over the SPI-bus just fine. However, on the USB-side, the MAX3421E > chip instead writes a 64-byte packet full of zeroes (which is the data > we were transmitting before). The mass-storage peripheral afterwards > NAKs any OUT request because it never saw the new SCSI WRITE_10 > command that was encapsulated in the "USBC" command. Okay. Maybe this would have been easier to see if you had been writing actual data instead of just a lot of zeros; the errors would have shown up when you checked the received data (incorrect checksum or something like that). > The work-around for now is to write outgoing packets twice, so that > both FIFOs contain the same data. With that workaround, we have been > able to dd 5MB blocks of data repeatedly without any issues (dd > if=/dev/zero of=/dev/sda1 count=5000 bs=1024). That sounds like you would sacrifice a lot of speed, because you are effectively using single buffering instead of double buffering. > I should mention this is with rev 0x12 of the MAX3421E chip. The > current rev is 0x13 so we'll try with that chip in the next few days. > However, we are not aware of any erratas for rev 0x12 that would > explain this behavior. You could try contacting the chip's manufacturer. > Also, for the record, we ran the SPI bus at only 4MHz for this testing > so we could reliably capture the data with the Saleae Logic. Giving > this low frequency and the fact that the Saleae was able to capture > the correct data, I do not think that SPI corruption is to blame. We > saw the same error occur even with SPI at 1MHz. > > I have the full trace data if anyone is interested. It's captures the > complete test (from loading the max3421 driver to when the error > occurs), so it's 55MiB in size, so I can't attach it to email. Thanks for letting us know the end of the story. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
