libftdi Archives

Subject: I've discovered the nature of my problem, but I don't know how to fix it... can anyone suggest something?

From: John Oyler <john.oyler@xxxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Cc: Michael Plante <michael.plante@xxxxxxxxx>
Date: Thu, 9 Sep 2010 10:55:30 -0500
I've borrowed my code from flashrom (which I'm very grateful for... without it 
I doubt I'd ever gotten anything to work).

The flashrom guys have the following function, which they use to read back SPI 

                static int get_buf(struct ftdi_context *ftdic, const unsigned 
char *buf, int size) {
                        int r;
                        r = ftdi_read_data(ftdic, (unsigned char *) buf, size);
                        if (r < 0) {
                                printf("ftdi_read_data: %d, %s\n", r, 
                                return 1;
                        } else if (r == 0) {
                                printf("\nLooks like our read failed.\n");
                                return 2;
                        return 0;

They were initially only checking r for negative values, which indicate actual 
errors. It will also occassionaly for me (say 30% of the time) return 0, 
indicating zero bytes read. When it's called again a second time with all the 
SPI-read-goodness, I'll then get the value I've expected... but the SPI chip 
I'm talking to has viewed that as two reads, thinking its internal FIFO has one 
less byte to read. Meaning that it cuts me off too early.

I'm of course reading through libftdi's source code and the ftdi_read_data() 
function, but I'm at a loss for how to fix this. If I do a full SPI read, the 
Semtech chip will have still counted the failed read prior and the current one 
as well. Is my byte just stuck in some USB buffer purgatory? Is it stuck in the 
FTDI chip (the data sheets mention *nothing* about any such thing, this I 
highly doubt). I don't think it's stuck in the Semtech chip, because that would 
mean it's internal pointer is changing for the read attempt when the clock 
toggles, but that it's not putting data on MISO. If so, I think it's at the 
very least buggy but maybe even defective... and they have too many customers 
for me to not be able to find any such complaints via Google.

Can anyone offer any advice? Is it possible to overcome this without straying 
into libusb territory?

John O.
libftdi - see for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx

Current Thread