[flashrom] SPI status register writes

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Jul 26 22:27:32 CEST 2010

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.



More information about the flashrom mailing list