My understanding is that typical flash memory failures, such as those due to erase cycles, occur at the bit level. I have a flash in which entire blocks (actually two blocks) are failing. Is there a common explanation for this?

More specifically, I have two blocks in a NAND flash device which are failing. These blocks are separated by one working block. The two failing blocks can be erased (I can confirm by reading by all ones), but after programming with 'random' data all of the bits are shown as all zeros.

Both blocks appear to have failed 'simultaneously'

I know that the flash part is nowhere near its max erase-cycle spec of 100k cycles.


closed as unclear what you're asking by David Gardner, Null, Daniel Grillo, Fizz, PeterJ Nov 19 '15 at 10:55

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


It could a number of things, you don't say what generation or device type etc. so specific's will be lacking. Some devices are made with extra blocks and during test if a block is found bad the other block is routed into it's place through programmable switches.

The routing channels for the substitutional blocks may have gone bad and depending upon the location of the blocks that could also explain why the pattern that you are seeing (2 blocks separated by one).

The most likely situation is that the chip died, or was hurt with ESD.


Depending upon how error-correcting codes are implemented, it may be possible for a chip to detect a larger number of bad bits than it can reliably correct. If a chip detects the existence of uncorrectable errors, having it return all-zero data may be safer than having it try to correct the data, especially if software tries to add its own error-correcting logic. Personally, I think the "right" approach would be to have a standard means via which a chip could give an indication of data reliability (block is "clean", block has correctable errors but can tolerate more, block is near the limit for correctable errors, block has unrecoverable errors, etc.) but in the absence of such a feature I wouldn't think it unusual for blocks to transition rather abruptly between working perfectly and being totally useless.

  • \$\begingroup\$ I'd say that upon detection of the first (not-expected) error a block should at least be marked read-only to avoid loss of data and, as soon as it's logically cleared/overwritten the next time, permanently marked unusable. Anything in between ('half-broken') seems like an unreasonable trade-off of reliability vs. perceived device lifetime. \$\endgroup\$ – JimmyB Nov 6 '14 at 15:27
  • \$\begingroup\$ @HannoBinder: I don't disagree with you, though a difficulty of that approach is that it may make device testing more difficult (since many devices would during testing be deliberately programmed with various error patterns). On a related note, I've often wished that data sheets would explicitly allow blocks to be overwritten with solid zeroes regardless of previous content (most data sheets only allow each page to be written once, and the tag area to be written once), since that would facilitate some management schemes. It would also be helpful if e.g. the last four bytes of the tag area... \$\endgroup\$ – supercat Nov 6 '14 at 16:31
  • \$\begingroup\$ ...could be written separately from everything else (at an arbitrary later time), so as to allow blocks to be marked "superceded by XXX". I don't think the circuitry for that would be difficult; it would simply be a matter of ensuring that ECC blocks didn't span that boundary. I've never seen such a documented behavior on a chip with any sort of ECC, however. \$\endgroup\$ – supercat Nov 6 '14 at 16:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.