Numonyx NOR and chip->mutex bug?

[Michael Cashwell]

On Feb 3, 2011, at 4:50 AM, Joakim Tjernlund wrote:

>>> My failures were caused by the erase-resume status read "seeing" a non-busy WSM. Adding a 20µs delay before that read (actually after the command write, but it amounts to the same thing) prevents this from happening. By the time awakened "wait-for-completion" code does its first status read it sees the WSM as busy as it should until the erase actually finishes.
> 
> Perhaps you can test for ESS(SR.6) too?
> something like:
>  if DWS && !ESS

Hmmm. So instead of a blind delay it would loop (with a timeout) while DWS && ESS are both set (meaning the erase resume command just written hasn't yet taken effect). It does make sense that if the resume takes time to drop SR.7 (ready) that it would also take time to drop SR.6 (ESS).

I like that. I'll add that to the set of tests today and report back.

-Mike