# Reading EEPROM memory (Winbond W25M02GV) with FT4222H USB bridge

I would like to read an EEPROM Memory (SPI Flash Winbond) using an FTDI USB/SPI bridge (FT4222H). I developed a c++ application that connects to the FTDI and reads data from the memory(and using the FTDI library). I am using the continuous mode read because it's much faster than the buffer read. The problem is that the FTDI transfer limit is 64Kbytes and the total memory is 256MBytes so I have to read 64Kbyte in a loop of 4096 times and then save it in a file. The problem is that each time you have to send the OpCode of reading memory followed by 7 Dummy Bytes, which I lost each time 8Bytes in each 64Kbyte.

I tried to read less then 64Kbye (for example 60Kbyte +8Byte) but I realize that the data was corrupted and is not properly read. Also, I tried to fix the starting reading page in each 60Kbyte but the same, the data was corrupted.

Does anyone have an Idea about that or he reads data through an FT4222 bridge?

And Thank you very much :)

Here the code bellow:

uint8* FTDIQuodSendRecieve(uint8 *Tx, uint16 *byteToread){

uint8 R[80535];
uint8 *Rx=R;
uint16 sizeTransfered;

if((ft4222Status!=FT4222_OK) )
{
std::cout <<"single read write failed "<<ft4222Status;
return 0;
}
return Rx;
}

ft4222Status = FT4222_SetClock(ftHandle, SYS_CLK_60);
if (FT4222_OK != ft4222Status){

// set clock failed
std::cout<< "set clock failed";
return 0;
}

if (FT4222_OK != ft4222Status){

std::cout<< "spi master init failed";
return 0;
}
return 1;
}

void saveFile(QTextStream *outStream,uint8 *Rx){

for (unsigned int i=7; i<32772; i++){ // all data was shefted with 8 bytes

if ((i-7)%2048 ==0){
*outStream << "\nPage "<< Page++ <<": ";
}

*outStream <<hex<< Rx[i]<<" ";
}
*outStream << "\n";
}

QElapsedTimer timer, total;
uint8 Tx[4];
uint8 Tx1[65535];
uint8 Rx= new uint8 [65535];

/*Memory reset*/
Tx[0]=0xFF;Tx[1]=0xB0;Tx[2]=0x00;
FtdiError(ft4222Status);

Tx[0]=0x13;Tx[1]=0x00;Tx[2]=0x00;Tx[3]=0x00;
FtdiError(ft4222Status);

Tx[0]=0x01;Tx[1]=0xB0;Tx[2]=0x00;
FtdiError(ft4222Status);

Tx[0]=0x0f;Tx[1]=0xB0;
std::cout <<  std::hex <<Rx[3]<<"\n";

/*If Continious Mode Then start reading */
if (Rx[3]==0x00){

total.start();
for (unsigned int i=0; i<8192 ;i++){

timer.start();
std::cout << "64Kbyte took " << timer.elapsed() << " milliseconds\n";
saveFile(outStream, Rx);

}
}
else {

std::cout<< "\n\nERROR Continious read not fixed";
}
std::cout << "64Kbyte *10 Time is: " << total.elapsed() << " milliseconds\n";
}

• Sounds like you need to debug your program, but at present you don't really have a specifically answerable question. Try putting a known pattern in flash, and do smaller reads to test your scheme. You might use a cheap USB based logic analyzer as a cross-check. Higher performance implementations of this goal would use a USB-capable MCU, keep the actual flash operations between the MCU firmware and the flash chip and merely use the USB to send back the results, either in a custom way or by implementing USB mass storage to give a raw block device. – Chris Stratton Sep 30 '20 at 16:01
• If 64kB is too much, why read almost 64kB and then 8 bytes? Why not then just use 32kb blocks to begin with? – Justme Sep 30 '20 at 16:15
• @Justme Yeah I reduce the reading from 64Kb to (60Kb +8byte) block. – mohamed bousselmi Oct 1 '20 at 5:26
• @ChrisStratton Thank you very much for your response :) I already debug my program and I get missing data too, I cannot go debugging inside FTDI-reading-function cause it's a DLL library. – mohamed bousselmi Oct 1 '20 at 5:47
• @ChrisStratton I tried continuous read with micro-controller and I get all the memory without missing data( the micro-controller doesn't use the FTDI-library and it's directly connected to spi port). I am thinking that the problem cames from the FTDI library cause the function itself puts the chip select High and low automatically while just coping one 64Kbyte block (tested with an oscilloscope) which I think misses some data while reading (cause in continuous mode the chip select must be low in all reading process not block by block). – mohamed bousselmi Oct 1 '20 at 5:47