On 17/12/2019 08:57, Vignesh Raghavendra wrote:
Hi Tudor,
On 12/16/2019 11:39 PM, Tudor.Ambarus@xxxxxxxxxxxxx wrote:
[...]
But, as you may see, it seems that my change to spi_nor_write() is still
required to stop the first unlock failure message, but it needs to be
relocated to after write_err label, as we now jump there for
spi_nor_wait_till_ready() failure. I guess the equivalent relocation is
also required for spi_nor_erase().
Or maybe spi_nor_wait_till_ready() should clear this flag always.
I reproduced this on a n25q256a, with both erase and write. Did a lock,
an erase or write, and then the unlock raises an error on the read back test:
it receives 0x02 to write (the prev operation let the SR.WE set to 1),
and after write, it reads back 0x00 (which is correct, WE is de-asserted).
What is pretty strange is that Micron says about erase or program operations
that: "When the operation is in progress, the write in progress bit is set
to 1. The write enable latch bit is cleared to 0, whether the operation is
successful or not".
So what I guess it happens, is that when an erase/write command tries to
modify a software protected area, the flash completely ignores the command,
so no Write In Progress, and no clearing of the WE.
From PROGRAM Operations section of mt25q datasheet:
" When a command is applied to a protected sector, the command is not
executed, the write enable latch bit remains set to 1, and flag status
register bits 1 and 4 are set."
So, Data sheet is quite clear about this and SW would need to clear WEL
(if required) after write failure.
Yeah, I think that the datasheet could have been better written in that
regard.
So about "whether the operation is successful or not" - I wonder what
they mean by "successful". Does it mean simply that the command
completes, even with error?
Thanks,
John
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
