On 26.07.2010 22:09, Daniel Lenski wrote:
On Mon, 2010-07-26 at 20:35 +0200, Carl-Daniel Hailfinger wrote:
Quite a few SPI flash chips need a few milliseconds to write the status register (AT25 series etc.), but we do not take care of this at all. The same flash chips ignore any commands sent while the status register write cycle is in progress. Given that we execute WRSR once per write, I think it is pretty OK to have a 100 ms programmer delay after WRSR. An alternative would be to watch the status register contents, but that may or may not work, the datasheets are completely unclear about that case. If we're lucky, this will even solve a few write/erase issues we were seeing.
Most of the AMIC datasheets explicitly state that bit 0 of the status register indicates completion of the WRSR operation, e.g. the A25L032 datasheet:
The Write In Progress (WIP) bit [SR bit 0] is 1 during the self-timed Write Status Register cycle, and is 0 when it is completed. When the cycle is completed, the Write Enable Latch (WEL) is reset.
Good point. RDSR checking would definitely work here.
The AT25DF021 datasheet states this more generally:
The RDY/BSY bit [SR bit 0] is used to determine whether or not an internal operation, such as a program or erase, is in progress. To poll the RDY/BSY bit to detect the completion of a program or erase cycle, new Status Register data must be continually clocked out of the device until the state of the RDY/BSY bit changes from a logical "1" to a logical "0".Presumably "an internal operation" includes WRSR?
Yes, but I'm not sure if "must be continually clocked out" means that we may run RDSR only once, but we can continue reading the response for thousands of cycles until RDY/BSY is 0. In that case the exercise would be rather pointless and a timer would be the only chance.
What about delay-then-RDSR?
Either way we need to fix this, and preferably before people stumble over this in real life.
Regards, Carl-Daniel