we use the following flash chip in our product: CYPRESS, S25FL128SAGMFI001.
Unfortunately, several chips failed after a while. Our host system is not able to read the Manufacturer Signature (Command READ_ID (REMS)). The failure affects 10 out of 100 devices. When could this condition occur?
What happens when the maximum number of write/erase cycles to a fix memory address of a 4K sector is reached?
Does the Flash module organize itself internally and does it have a kind of mapping?
If a 4K sector is no longer writable, should it still be possible to read out the manufacturer signature?
Could you help me with the question?
Thanks and looking forward to your reply.
When could this condition occur? Reading device ID is the most basic flash operation. If the CS# signal and SPI transaction is fine and the command still does not work, then this generally indicates some hardware connection issue. Could you please check your hardware connection once again?
What happens when the maximum number of write/erase cycles to a fix memory address of a 4K sector is reached? The program/erase/read operations to that particular sector are not guaranteed any more. The flash may or may not give proper results.
Does the Flash module organize itself internally and does it have a kind of mapping? No, there is no internal wear levelling algorithm in FL-S memory.
If a 4K sector is no longer writable, should it still be possible to read out the manufacturer signature? As per my understanding, yes. If the PE cycles for a particular sector is exhausted, it only affects that sector. Could you please elaborate the issue a little more? Please answer my below question -
Thank you for your detailed answer.
I answer your questions below:
Could you please check your hardware connection once again? The hardware connection was checked by our hardware developer. After replacing the flash chip, the control worked again.
You have mentioned that 10 out of 100 devices are showing this behavior. Are all these 100 devices being used in a similar application? The same application runs on all devices. However, depending on the operating status of the hardware, there may be devices where a 4K sector is programmed/erased more often. So it could well be that some devices had more than 100000 write cycles on a 4K sector.
Is the same code being used in all 100 devices to read the device ID and 10 out of the full 100 are not giving proper output? Yes, the same source code is used for all devices. To read out the manufacturer signature, we use the command 90h.
What do you mean by "Our host system is not able to read the Manufacturer Signature"? What is the output that you are receiving on these 10 defective devices when you tried reading the device ID? I mean that the command 90h (Read Electronic Manufacturer Signature) did not get a response from the SPI chip. We checked with a logic analyser that the signals on MOSI, SCKL and CS were correct. Nothing came back on the MISO line.
Did you try to capture the SPI signals for reading device ID operation? If yes, can you please share it with us? I try to share screenshots from the Logic Analysis as soon as possible.
Did you try the 9Fh command? What is the output that you observed? I have only used the 90h command so far. Does the command 9Fh behave differently?
Did you try to program/erase/read any other sector (apart from the excessively used 4K sector) on the failing units? Did you receive the expected output? With the defective devices, neither command 90h nor write or read commands worked.
Therefore, once again the explicit question, how likely is it, when the write cycles of a 4K sector have been reached, that the module no longer responds to the commands mentioned above? I suspect that the 10 devices have defective memory modules. What do you think?
I discussed your question internally. Reaching the max number of P/E cycles for the 4K sectors will have no impact on reading the manufacturer ID. This may be due to a too tight read timings that can fail when devices will be aging. You may try to send a reset command (0xF0) before trying the command 90h and see if it still fails.
Does the command 9Fh behave differently? Similar to 90h command, the 9Fh command also reads the device ID and manufacturer ID, but it does not need any address. So it is comparatively simpler than 90h command.
We received a new production PCB with new flash modules last week. The PCBs were washed by the service provider. For temperature tests the PCBs came additionally in cold/heat chamber (-20°C to +50°C).
Out of 40 devices there is again 1 device with the above described error. Our hardware developer has checked the conductor tracks and the PCB. Everything is OK.
I have implemented the F0h (Reset) and 9Fh (Read Identification) commands in the software. There was no other behavior to be seen. There were no signals on the MISO line.
We were able to record the following signals with a logic analyzer on the defective and functional device:
Command F0h - defect device:
Command F0h - functional device:
Command 9Fh - defect device:
Command 9Fh - functional device:
Command 90h - defect device:
Command 90h - functional device:
It is easy to see that nothing happens on the MISO line of the defective device.
There are many indications that the flash memory is defective. The error pattern is the same as in the previously delivered devices.
Do you have any other ideas how the defect could be caused and is there a possibility to have the defective component checked?