DQ5 & DQ6 in chips/cfi_cmdset_0002.c (Dairy Queen 5 warning)

[Steve Wahl]

On Wed, Mar 12, 2003 at 12:12:12PM -0500, John Burch wrote:
> AMD's own method from code they provide is shown below...
> 
> By the way, AMD specifically mentions having to check DQ6/7 again
> after DQ5=1 because of the possibility that DQ5=1 simultaneous with
> toggling stopping.  The app note I referred to before (attached this
> time) describes this in some detail.  

I agree with this.

> The status register (including DQ5) won't reflect actual data until
> a reset command is issued,

This I think is a misunderstanding or misstatement on your part.  The
reads WILL return to actual data without a reset upon successful
completion of the operation.  Only on a failure does software need to
issue the reset to return to reading data!

The app note you attached agrees with me on this.

> so I think the concern about DQ5=1 because erased data (0xff) is
> read instead of status is not valid.

I disagree.  This concern is indeed valid, and is the primary reason
you must check for toggling AFTER noticing DQ5=1 in the first place.

Note that cfiflash below does not handle interleave nor bit
endianness, so you can't adopt it directly.

--> Steve

> John
> 
> >From AMD's cfiflash.c:
> 
> /*********************************************************************/
> /* Flash_status utilizes the DQ6, DQ5, and DQ3 polling algorithms    */
> /* described in the flash data book.  It can quickly ascertain the   */
> /* operational status of the flash device, and return an             */
> /* appropriate status code (defined in flash.h)                      */
> /*********************************************************************/
>  
> int flash_status(word far *fp)
> {
> 	 unsigned char d, t;
> 	 int retry = 1;
> 
> again:
> 
> 	 d = *fp;        /* read data */
> 	 t = d ^ *fp;    /* read it again and see what toggled */
> 
> 	 if (t == 0) {           /* no toggles, nothing's happening */
> 		return STATUS_READY;
> 	 }
> 	 else if (t == 0x04) { /* erase-suspend */
> 		if (retry--) goto again;    /* may have been write
> completion */
> 		return STATUS_ERSUSP;
> 	 }
> 	 else if (t & 0x40) {
> 		if (d & 0x20) {     /* timeout */
> 		  return STATUS_TIMEOUT;
> 		}
> 		else {
> 		  return STATUS_BUSY;
> 		}
> 	 }
> 
> 	 if (retry--) goto again;    /* may have been write completion
> */
> 
> 	 return STATUS_ERROR;
> }
> 
> 
> 
> > -----Original Message-----
> > From: linux-mtd-admin at lists.infradead.org 
> > [mailto:linux-mtd-admin at lists.infradead.org] On Behalf Of Steve Wahl
> > Sent: Wednesday, March 12, 2003 11:28 AM
> > To: Thayne Harbaugh
> > Cc: linux-mtd at lists.infradead.org
> > Subject: Re: DQ5 & DQ6 in chips/cfi_cmdset_0002.c (Dairy 
> > Queen 5 warning)
> > 
> > 
> > Thayne, 
> > 
> > I have a patch that I was given permission to check in, but 
> > never got around to it, that covers a similar "DQ5 raised" problem.
> > 
> > I would wager you are running into the same problem I did, 
> > and that your chips compatibly support DQ5, if not as a 
> > watchdog, at least by holding it low while programming.
> > 
> > Can you look at my previous posts on this, try my patch (if 
> > you don't have interleaved chips -- contact me if you do), 
> > and see if it works for you?
> > 
> > http://lists.infradead.org/pipermail/linux-mtd/2003-January/00
> > 6780.html
> > 
> > --> Steve
> > 
> > 
> > On Tue, Mar 11, 2003 at 05:25:15PM -0700, Thayne Harbaugh wrote:
> > > For some reason I am confused: I get the feeling that what 
> > I'm trying 
> > > to understand is obvious - I just can't see the forest for 
> > the trees.  
> > > Will someone help me understand?
> > > 
> > > cfi_cmdset_0002.c has several functions that use dq5 and dq6 for 
> > > monitoring the status of erase and write operations:
> > > 
> > > dq6 = CMD(1<<6);
> > > dq5 = CMD(1<<5);
> > > 
> > > Apparently, from the code dq6 toggles during erase/read 
> > operations and 
> > > dq5 is low until the erase/read operation times out and 
> > then goes high 
> > > (somewhat like a watchdog bit).
> > > 
> > > My understanding, at least for the SST 49LF040 and PMC Pm49L004 is 
> > > that dq6 toggles during erase/write and dq7 is inverted until the 
> > > erase/write operation completes.  This causes me to expect 
> > to see the 
> > > following code rather than what is written above (not to 
> > mention that 
> > > most everything in do_write_one_word() should be adapted for dq7 
> > > invert):
> > > 
> > > dq7 = CMD(1<<7); /* invert */
> > > dq6 = CMD(1<<6); /* toggle */
> > > 
> > > The differences give me the feeling that there really are two 
> > > different classes of cfi_cmdset_0002 - those devices that 
> > have a dq5 
> > > watchdog and those devices that don't have the watchdog, but have a 
> > > bit inverter on dq7.
> > > 
> > > Am I not understanding what happens on bits 0-5 during an 
> > erase/write 
> > > operation?  The PMC and SST chips don't mention a thing about dq5 
> > > behavior.  If they don't have the dq5 watchdog timer then they will 
> > > behave in an undefined way (depending on the state of bit 5 in the 
> > > written word) with the current dq5 checking.  This explains 
> > the many 
> > > warnings I see with the SST and PMC chips in do_write_oneword(),
> > > 
> > > "Warning: DQ5 raised while program operation was in 
> > progress, however 
> > > operation completed OK"
> > > 
> > > Around here we refer to this as the "Dairy Queen 5" warning.
> > > 
> > > Obviosly, during an erase that completes prior to dq5 being 
> > read-back, 
> > > dq5 will be high and the current algorithm is erroneously correct.  
> > > This can explain why I have not seen the same message in 
> > > do_erase_oneblock().
> > > 
> > > Furthermore, the SST documentation on page 10 refers to "spurios 
> > > rejection" of good writes - differentiating between a write that 
> > > succeeds that appears to fail and a write that fails.  It 
> > says that a 
> > > write that appears to fail needs to be read back two more times 
> > > successfully to filter out spurious rejection.
> > > 
> > > Comments?  What should change to improve the operation completion 
> > > check?  Should cfi_cmdset_0002 be adapted to handle 
> > multiple types of 
> > > polling or should another command set be written?
> > > 
> > > --
> > > Thayne Harbaugh
> > > Linux Networx
> > 
> > 
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >