完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
德赢Vwin官网
论坛|
您好!
在我们的系统中，几个Xilinx ZYNQ SoC从S25FL512S闪存启动。 两周前，ZYQS中的一个在电源循环后没有启动，这可以通过重新编程闪存来恢复。 上周，三个SoC无法启动，但重新编程闪存是不可能的。 S25FL512S的寄存器表明，块保护被某种方式激活： 状态1：0x9C 状态2：0x00 配置1：0xEA 在相同的功率循环下有三个器件失效是系统性的，但是我们在系统中有大约20个器件，使得它在20的比率中占3。 数据表说TBPROT和BPNV是OTP，这让我相信Flash在某种“致命错误数据恢复”模式中。 此外，我认为写和擦除保护不应该阻止设备读取闪存引导。 有人能给我一个暗示，是什么导致了这个状态，还是它可以被恢复？ 马克斯 以上来自于百度翻译 以下为原文 Hi In our system several Xilinx Zynq SoCs are booting from S25FL512S flash. Two weeks ago one of these Zynqs failed to boot after power-cycling, which could be recovered by re-programming the flash memory. Last week three more SoCs failed to boot, but re-programming of the flash wasn't possible. The S25FL512S's registers indicate that Block Protection was somehow activated: Status1: 0x9C Status2: 0x00 Config1: 0xEA Having three devices failing on the same power-cycling feels systematic, however we have about 20 devices in the system which makes it a 3 out of 20 ratio. The data sheet says TBPROT and BPNV are OTP, which makes me believe the flash is in some kind of "fatal error data recovery" mode. Further more I think WRITE and ERASE protection shouldn't prevent devices from reading the flash for booting. Could someone please give me a hint at what led to this state, or even if it can be recovered? Max 
0
|
|
相关推荐
3个回答
|
|
|
你好，马克斯，
可能的原因之一可能是在启动时写寄存器操作中的功率损失。 请参考下面给出的链接中的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. |
|
|
|
|
60user47 发表于 2018-11-28 09:05 你好，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 |
|
|
|
|
fhdgxfvx 发表于 2018-11-28 09:19 你好，马克斯和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 |
|
|
|
|
只有小组成员才能发言，加入小组>>
754个成员聚集在这个小组
加入小组2102 浏览 1 评论
1848 浏览 1 评论
3666 浏览 1 评论
请问可以直接使用来自FX2LP固件的端点向主机FIFO写入数据吗？
1783 浏览 6 评论
1533 浏览 1 评论
CY8C4025LQI在程序中调用函数，通过示波器观察SCL引脚波形，无法将pin0.4(SCL)下拉是什么原因导致？
564浏览 2评论
CYUSB3065焊接到USB3.0 TYPE-B口的焊接触点就无法使用是什么原因导致的？
418浏览 2评论
CX3连接Camera修改分辨率之后，播放器无法播出camera的画面怎么解决？
434浏览 2评论
380浏览 2评论
使用stm32+cyw43438 wifi驱动whd，WHD驱动固件加载失败的原因？
911浏览 2评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
3865
评论
淘帖
460
