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).