- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Reading the manufacturer Id etc. does not work.
For all communication attempts the device does not respond.
The same Software works on another Hardware.
We have the Problem, that this behaviour keeps on Happening on our boards and we don't know why this is Happening.
I tried to write to reset the device with the Software Reset command by writing a Software reset enable (0x66) first, followed by a Software reset (0x99).
I also tried to send the mode bit reset command first (0xff).
All These attempts seems to have no affect at all.
We have to investigate the cause of this, because changing the flash-chip on the board solves the Problem but this should not be the case.
Does anyone has any idea?
Thanks in advance!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andre,
I see. Thanks for explaining.
I think this KBA (Knowledge Base Articles) may interest you: Power Loss During the Write Register (WRR) Operation in Serial NOR Flash Devices – KBA221246
Power Loss During the Write Register (WRR) Operation in Serial NOR Flash Devices – KBA221246
Perhaps in your previous tests, some devices lost power during the WRR operation, resulting in corruptions in some non-volatile registers. It is important that in your software, you want to minimize the windows of potential corruptions. We suggest that the software reads the register values first, compares them with the desired values, only does WRR if values are different, Usually after this implementation, there should not be any register corruptions because there are no frequent WRR operations in most software applications.
Hope the KBA and the App Note (AN200381) quoted inside the KBA will help you.
Thanks,
Zhi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
What command did you use to read the manufacturer ID? Note that S25FL256L supports the 0x9F command, but not the 0x90 command.
Please let us know to which command the device did not respond.
Thanks,
Zhi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey,
thanks for the Reply.
I used the 0x9f command and i already have a working board where the S25FL256L responds with the correct manufacturer ID.
The issue here is that we have a few boards where the Flash is not responding anymore and we don't see any reason why this could happen.
Changing the Flash ic on the board fixes the Problem, but we Need to find out what causes this error.
Thanks,
Andre
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andre,
My understanding is that a new FL256L device would work fine, but it may become not responding some time after. Is that right?
What kinds of operations are performed on the flash before it became bad? Were you doing some power cycle testing?
Thanks,
Zhi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Zhi,
yes your understanding is correct.
At the Moment, all that is being performed is the following at power up the Hardware:
1. Enable QuadMode ( WREN(0x06) and WRR(0x01) )
2. Update Adressing ( WREN(0x06) and WRAR(0x71) )
3. Quad Output Read ( 0x6c)
After this initialization the Flash is currently not used by our Software.
I performed an test, where i did this initialization in a Loop for more than 8 hours to check if this init crashes the Flash somehow, but this did not damage it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andre,
I see. Thanks for explaining.
I think this KBA (Knowledge Base Articles) may interest you: Power Loss During the Write Register (WRR) Operation in Serial NOR Flash Devices – KBA221246
Power Loss During the Write Register (WRR) Operation in Serial NOR Flash Devices – KBA221246
Perhaps in your previous tests, some devices lost power during the WRR operation, resulting in corruptions in some non-volatile registers. It is important that in your software, you want to minimize the windows of potential corruptions. We suggest that the software reads the register values first, compares them with the desired values, only does WRR if values are different, Usually after this implementation, there should not be any register corruptions because there are no frequent WRR operations in most software applications.
Hope the KBA and the App Note (AN200381) quoted inside the KBA will help you.
Thanks,
Zhi