块保护后S25FL512S恢复？

你好，马克斯，
可能的原因之一可能是在启动时写寄存器操作中的功率损失。
请参考下面给出的链接中的KB文章，它解释了如果不正确地写入寄存器操作，则会恢复。
串行NOR闪存器件写寄存器（WRR）操作期间的功率损失
谢谢，
Krishna。



     以下为原文
  Hello Max,
 
One of the possible reasons could be power loss during write register operation when you boot up.
Please refer to the KB article from the link given below which explains about the recovery if incorrect  write register operation has been performed.
Power Loss During the Write Register (WRR) Operation in Serial NOR Flash Devices – KBA221246
 
Thanks,
Krishna.

你好，Krishna，
谢谢你的回答。
我们不是在我们的代码中发布WRR，但是在第一级引导加载程序所使用的Xilinx QSPI驱动程序中，我发现了“XQSPIPSHFLASHOPCODEDWRS0x01/0*写状态寄存器*/”。因此，在引导过程中，四位确实是被设置的，正如KBA中提到的那样。
启动期间的功率循环是系统可能发生的事情。
所以我的急性问题：
据我所知，我不能重置BPNV的OTP比特为零。因此，BP0-2将默认为1，在开机后留下闪存锁定。
但是，如果我可以将SRWD重置为零（不知道WP状态），那么至少有机会重置易失性位吗？
马克斯



     以下为原文
  Hello Krishna,
 
thank you for the answer.
 
We are not issuing WRR in our code, but I found "XQSPIPS_FLASH_OPCODE_WRSR    0x01 /* Write status register */" in the Xilinx qspi driver used by the first-stage bootloader. So perhapse the QUAD bit is indeed set during boot, as mentioned in the KBA.
Power-cycling during boot is something that could have happened to the system.
 
So w.r.t. my acute problem:
As far as I understand I won't be able to reset the OTP Bit for BPNV to zero. Hence BP0-2 will default to 1, leaving the flash locked after power on.
But if I could reset SRWD to zero (don't know about the WP# state), there could at least be the chance to reset the volatile bits?
 
Max

你好，马克斯和Krishna，
我也面临同样的问题。我还在使用ZYNQ SoC设备，在FSBL中读取分区头遇到了一些问题。在添加QSPI支持之后，问题就消失了，但我发现了另一个问题，目前的问题是砖块设备。
该数据表对Quad Ouptut Read说：“配置寄存器的四位必须设置（CR BIT1＝1）以使四模式能力。”这就是为什么我添加了WRR命令来启用基本上工作的QSPI位模式，并解决了我提到的问题。但现在我还有另一个更关键的问题！
在启动过程中的功率损失后，S25FL512S设备进入未定义状态。状态寄存器值类似于马克斯已经发布的值（SR1:0x9C，CR1:0xEA）。在再次执行WRR命令之后，Flash我甚至不能读出设备ID。
在我的FSBL中删除WRR命令并用另一个硬件测试时，我也得到了U-BooD引起的同样的问题。我发现SPIHFLASHETSETQQUE（）函数也执行WRR命令。Linux内核也可以执行WRR命令。
直到现在，我不能让我的破碎闪光灯设备再次工作。在我的应用中，保证电源稳定状态的最佳实践建议是不能保证的。
所以我的问题是：有没有机会让闪存设备回到工作状态？
谢谢，
马蒂亚斯



     以下为原文
  Hello Max and Krishna,
 
I'm facing the same issue. I'm also working with a Zynq SoC device and faced some problems reading the partition header within my FSBL. After adding QSPI-support the problem was gone, but I found another problem which currently lead to bricked devices.
 
The datasheet says for Quad Ouptut Read: "The QUAD bit of Configuration Register must be set (CR Bit1=1) to enable the Quad mode capability." That is why I added the WRR command to enable the QSPI-bit mode which is basically working and solved my mentioned problem. But now I have another much more critical problem!
 
After a power loss during startup the S25FL512S device got in to an undefined state. The status register values are similiar to the values Max already posted (SR1: 0x9C, CR1: 0xEA). After executing the WRR command again the flash I wasn't even able to read out the device id.
 
After removing the WRR command in my FSBL and testing with another hardware I got the same issue caused by u-boot. I found the function spi_flash_set_qeb() is also performing a WRR command. The linux kernel may also perform a WRR command.  
 
Until now I'm not able to get my broken flash devices working again. The best practice recommendation to maintain a stable power supply condition cannot be guaranteed in my application. 
 
So my question is: Is there any chance to get the flash device back to a working state?
 
Thanks,
Matthias