I know this part has been obsoleted long time ago. However, we are still using it on a product as the main program memory.
As is (or was) common with these parts, code is executed in place, i.e. directly from the Flash itself.
We never write to the flash during normal operation, although we support firmware update on the field.
We were reported cases of memory corruption (which is detected by computing a CRC code), so we decided to investigate.
We analyzed two samples from the field and found that both of them had failed because of a single bit corruption (not the same bit and not in the same (H or L) data byte in the two cases, but just one bit out of the full 8 Mbits of the part in both cases); in both cases, corruption consisted into turning value 1 bits into 0 value.
Also, corruption was reversible, i.e. reprogramming the device fixed it.
We believe it is nearly impossible for this to have occurred following an out-of-control software jump to the programming routines used for Firmware Update, as we are sure a much more extensive corruption would occur if that ever happened.
We then read about the "Read Disturb" issue which however mostly affects NAND flashes, not NOR ones; we found a few references mentioning Read Disturb for NOR flash as well, but they were unclear whether this could occur on the very old process used for this part, or only on today's much more advanced processes. After all, if this could happen on this kind of device, would designs rely on in place code execution without taking any measure to increase robustness?
Other mechanism we are thinking about for the issue to occur is some spurious and short reset pulse which may be generated by the power supervisor chip e.g. following a brownout. Could this leed to the above described type of corruption, especially if such pulse does not also reset the processor?
And would it be more likely for such corruption to happen at (or near) locations the processor is currently reading (fetching code) at the moment the spurious pulse occurs? Asking this because in both cases corruption occurred at locations occupied by the code of the small "Idle" thread of the microkernel, which is the most frequently executed code (this would also be consistent with the Read Disturb theory, though).
Thank you for contacting the Cypress Community Forum.
1). Please provide the full Ordering Part Number (OPN) associated with the Am29F800B.
2). Is the Am29F800B exposed to high levels of radiation or high energy electrical field?
3). There may be the possibility that a short RESET pulse may cause data corruption/bit flip.
Please provide a screen shot of the short (H/W) RESET pulse, as well as the VCC level during
the (H/W) RESET operation for our review and analysis.
Cypress anticipates your prompt response...
Thank you in advance...
thnak you fro your reply:
2b) Strong electrical field: very unlikely
3) So far, a short reset pulse as the problem root cause is a theoretical exercise, given the existing power supervision circuitry could allow for this to happen in case of power brownout (or better a dip).
Therefore, currently we don't have scope shots available, but we plan to run some experiments.
Q.: How likely is that for corruption to occur a combination of short reset pulse and VCC drop would be required (e.g. as opposed to short reset pulse only)?
I am asking because we were planning to initially run experiments in which we only force short (30-200 ns duration adjustable) reset pulses by means of some additional circuitry, without actually impacting VCC supply. But, should this have too low or zero chance to cause a corruption, then we will modify our plan and shoot for testing actual VCC short drops.
Finally, can I take from your answer that the "Read Disturb" theory is not applicable to this part?
Thank you again
Yes, "READ disurb" is not applicable to the AM29F800BB-70SF, as the process technology node is quite large at ~320nM.
Therefore this design platform of the AM29F800BB-70SF is very robust. However, there may be the possibility the
AM29F800BB-70SF may already damaged upon your purchase. I recommend that you return the AM29F800BB-70SF
to the third-party vendor (or 'point-of-purchase') and request a refund or exchange for another lot of the AM29F800BB-70SF.