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. 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). 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. 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. --david On Thu, Mar 13, 2014 at 8:55 AM, David Mosberger <davidm@xxxxxxxxxx> wrote: > Yeah, sorry, the READ_10s were a total red herring. They're there > because I forgot to specify bs=1024. ;-( > > I'll try to capture better traces today and if they look interesting, > make them available. > > --david > -- > eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.976 -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- 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
