I know this forum is for high level NAND access, but maybe some can advice about NAND memory protocols.
I have been using https://github.com/bkerler/NANDReader_FTDI project to read NAND memory. Project works pretty well, but from time there are errors in read data.
Everyone says those are natural for poor quality NAND, but mine errors has common factor.
If they happend, they are always malform last byte of this so called Spare Area (or OOB data). Mistakes happen more frequently to specific pages.
From data perspective it is ussually non-zero byte malformed into zero in many bits, sometimes even 0xFF into 0x00.
General reproduction ratio is 10% at high speed (FTDI clocking 60MHz, which gives about 600kB/s) and almost 0% at low speed (FTDI 12MHz which gives about 400kB/s).
My test chip is Hynix H27U2G8F2C, 256MB chip desoldered from industrial equipment.

Any advice what could generate such problem? Is this normal when working with such old and small NAND memories?
How fast can read commercial tool like PC3000 or VNR read NAND memories?


So far I had considere following issues:

Idea: Control application waits to short, NAND is slow, maybe not enought time to copy last byte from memory to buferr, or app does not wait for RB line?
Answer: I added extra 100ms delay between addresing memory and read, did not change anything.

Idea: There is a problem with control lines like ringing, crosstalk?
Answer 1 But problem never happend on main memory where 2048bytes are transfered in one burst.
Answer 2 I made modification to read 63 bytes in one burst, and last byte in another 1byte burst, same result.

Idea: This last byte is lost/malformed in application.
Answer: I made modificiation to print on the screen just after it is received from FTDI, it is not altered

Idea: Adressing problem or malformed commands?
Answer: Pages are visually unique, first 63 bytes are ~100% correct, problem never happend with main memory


My last idea is to use logic analyzer to capture what is on data bus at the moment of malformed reads.
It kind problematic, how to capture one bytes among 256MB, so I am leaving this as last resort.

Can you try reading 63 bytes in one burst, and then follow it up with a 2-byte burst?

Is it the last byte in a page that is read incorrectly, or is it the last byte in a stream?

_________________
A backup a day keeps DR away.

To me this sounds like a protocol bug in the software. When I rewrote openocd to speed up it's JTAG protocol, I found some bugs where they first raised the data-ready signal and only afterwards sent the data. When the CPU is fast enough and the target is slow enough, this can work most of the time, but when an interrupt slows down the processing in the middle, or when the target is too fast, it will result in wrong data. So I would suggest to audit the software whether it sends and receives the signals in the correct order. Sometimes such mistakes can happen and go unnoticed.

Apologize for not answering, but for some reason while I made more experiments problem stopped reproducting.
I tried to capture length of RD pulse to make sure minimal time is met.

@fzabkar, nice idea, I was really dumb I haven't thought about it.
@sourcerer, protocol is too simple to make mistakes, but the problem might be with timing, FTDI chip has almost zero options to tune pulse lenght or timing between edges and moment when data bus is read/write. Surprising was why few specific pages among 100000 has higher reproduction rate and always last byte. The memory cell array should be kind uniform, pages are read and while RB stops pulling to ground, whole page should be in buffer.
Only thing which comes to my mind, there is sideeffect of reading next page to buffer,