On Monday 23 July 2007, David Brownell wrote: > > > If that hardware were doing the right thing, then it would work > > > reliably! Since it's not reliable, it's doing something wrong. > > > You seem to think it's not a hardware issue; that may be true. > > > > > > Recall that the first dozen or so commands worked just fine. The > > > issue was that some byte that should have been all-ones or 0xfe > > > reported instead an 0xf8. That's not the kind of error that can > > > be explained by clock skew; it covers at least two bits. > > > > Yup, I've either noticed that 0xf8 and 0xfe differs by only two > > bits (and by three if comparing to 0xff). But I can't really > > explain it yet.
Just for the record -- on my test rig, SPI mode 3 stopped working entirely ... I'd get one-bit errors, so that CMD0 status would be "0x03" instead of "0x01" (indicating CRC error plus still-resetting). Switching to SPI mode 0 made it all work again; masking out the 0x02 bit made everything time out. So I'm thinking that *was* somehow a shift of one bit. I think this was caused by removing wires for one SPI device from that breadboard ... but it's hard to say for sure. For a while it seemed like MMC cards worked OK but not SD cards! I'm working on a more permanent rig. But I think when I send the next revision to Pierre, it'll be using SPI_MODE_0. :) I thought you might be amused, given the strange behavior you saw! - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
