libftdi Archives

Subject: Re: Dropping byte 62+63 on SPI reads?

From: Paul Fox <pgf@xxxxxxxxxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Cc: Jeremy Buseman <naviathan@xxxxxxxxx>, Uwe Hermann <uwe@xxxxxxxxxxxxxx>
Date: Tue, 24 Nov 2009 10:01:45 -0500
what version of libftdi are you using?  this sounds a lot like a
problem i saw when first getting ft2232_spi.c to work (but i've
forgotten the details).  i recall that libftdi was buggy with
regard to 2232 devices when i was doing that work, so i was
building with (and still am building with) a private copy of
ftdi.c. 

since i've not seen the problem you're describing recently, i'm
guessing that my copy doesn't have the problem you're seeing?  doing
some foraging in my source trees, it appears that the copy of ftdi.c
i'm using is identical to that in my "libftdi.git" tree.  that
tree is at version e3d9bcdd6771a2464cd832b96e3da26a3ad804ac, from
git://developer.intra2net.com/libftdi

hopefully this isn't all just misleading information.

paul

carl-daniel wrote:
 > Hi,
 > 
 > I noticed a strange bug while debugging flashrom on the DLP-USB1232H
 > board. Basically, flashrom uses the MPSSE SPI interface, sends 4 bytes
 > SPI command, then reads 256 bytes SPI response from a chip attached to
 > the FT2232H chip on that board.
 > The common pattern in the broken case (with very few deviations) is
 > (counting starts at 0)
 > byte 0-61 are read just fine, byte 62-63 are skipped,
 > byte 64-125 are read just fine, byte 126-127 are skipped,
 > byte 128-189 are read just fine, byte 190-191 are skipped,
 > byte 192-253 are read just fine, byte 254-255 are skipped,
 > the last 8 bytes in the buffer are filled with zeros (or unchanged).
 > Basically, only the first 62 bytes of every 64 byte block are read and
 > the next 64 byte block starts two bytes too early.
 > Only a part of the transfers is broken that way, most are OK. It is
 > interesting that the broken transfers tend to cluster around specific
 > addresses.
 > 
 > We can circumvent the issue by limiting chunk size to 32 bytes, but
 > that's not a real solution. None of the libftdi transfer functions
 > return any error, so I was expecting the transfers to be reliable.
 > 
 > Jeremy (who owns the hardware) is in CC and he'll supply details about
 > libftdi, libusb, kernel and hardware soon.
 > Uwe owns the same hardware, but he is not seeing any issues yet (well at
 > least not when keeping the machine load low).
 > 
 > Regards,
 > Carl-Daniel
 > 
 > -- 
 > Developer quote of the month: 
 > "We are juggling too many chainsaws and flaming arrows and tigers."
 > 
 > 
 > --
 > libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
 > To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

=---------------------
 paul fox, pgf@xxxxxxxxxxxxxxxxxxxx (arlington, ma, where it's 43.5 degrees)

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread