additional error checks for AG-AND erase/write

[David A. Marlin]

The Renesas AG-AND chips support additional error checking on erase and
write operations beyond just checking the operation status.  I think the
logic is that since ECC can correct 2-bit errors on read, if only a
single bit error occurs on and erase or write the operation should not
be considered FAIL.  Even if a single bit error occurs on read (in
addition to the single bit error on write), it will still be corrected
and no data will be lost.

I'm looking at how to implement the additional status checks, and am
considering adding an optional callback routine to nand_base that, if
defined, would be called in the event of an erase or write error before
returning a FAIL status.  The nand_write routine would need to be
modified to perform the callback routine as follows:

<pseudocode>
     command(SEQIN)  // begin auto page programming
     enable_hwecc(WRITE)
     write_buffer(data)
     calculate the ECC  // from FPGA
     write_buffer(ECC)
     command(PAGE_PROGRAM)
+   if READY && (status & 0x01)  // Program Fail (I/O1=1)
+      && error_status_callback  //   and there is a callback
+     status = error_status_callback(page)
+   endif
     if READY && (status & 0x01)  // Program Fail (I/O1=1)
       return error
     endif


// The callback routine itself would need to perform the following:

error_status_callback(page)
     status = read_error_status
     if !(status & 0x20)  // ECC not available (I/O6=0)
       return error
     else
       ReadECCcheck(page)  // Read the data and check the status
       if (!1_bit_error)   // if Not 1 bit error
          return error
       endif
     endif
     return ok
</pseudocode>


One problem I see is that in order to determine if there is a 1-bit 
error, we must perform a "read" of the page in question, but the erase 
and write routines both hold a "lock" on the device through 
'nand_get_device'.  This would prevent the read from proceeding until 
the erase or write completed (deadlock).

Is there a better place to include additional status checks, or a more 
appropriate method of implementing this?  I would appreciate any 
suggestions.


Thank you,

d.marlin