S25FL064L NAND闪存不返回RDID命令的数据

嗨，Zhi，
它不是在失败& gt；模式。
在有限的意义上，芯片仍然是设计师的行为。
显然是有意的。当然，我同意在正确的地方
QPI环境-这不是一个问题。但在其他情况下
一种可能导致设备完全失效的设计决策
这个芯片在运行。
希望他们将来能有更好的设计。
我们总是生活在希望之中
再次感谢您在澄清这个问题上的帮助。
最好的问候
鲍勃
星期二，2018年3月27日09:30:05–0700



     以下为原文
  Hi Zhi,
 

it is not in failure > > mode.

In the limited sense that the chip is still behaving as its designers
apparently intended. And of course I'd agree that in the right place - a
QPI environment - it is not a problem. But in other circumstances it is
a design decision that can result in total failure of the equipment in
which the chip is operating.
 

Hopefully they will have a better design in the future.

We always live in hope  
 
Thanks again for you help in clarifying this issue.
 
Best regards
Bob
 
On Tue, 27 Mar 2018 09:30:05 -0700

嗨，Shalini，
你也能显示你的波形上的SO行吗？我们不知道它是否返回一个值。
谢谢，
智



     以下为原文
  Hi Shalini,
 
Can you also show the SO line on your waveforms? We don't know if it returns a value or not.
 
Thanks,
Zhi

先生，
SO线只是在地平面上，只有0级DC，我没有张贴它，这样你就可以清楚地看到所有其他波形。
提前感谢
关于问候
沙利尼



     以下为原文
  Sir,
 
The SO line is simply at ground level.0 level DC only, I did'nt post it so that you can see all other waveform clearly.
 
Thanks in advance
With Regards
Shalini

你好，
附件是来自CRO的SO线PIC。请建议如何进行。我被困住了。
关于问候
沙利尼



     以下为原文
  Hello,
 
Attached is the SO line pic from CRO. Please suggest how to proceed. I am stuck.
 
With Regards
Shalini
 

嗨，Shalini，
通常，我们想在同一个波上看到CS、SK、SI等。
我不知道为什么没有这样的输出。你在所有的设备上看到这个了吗？你能在其他设备上看到正确的输出吗？
S25FL040L也支持QPI模式。如果设置了该模式，则主机需要以4-4-4格式发送命令、地址和数据。我想知道您的设备是否已经设置为QPI。如果你可以修改你的主机控制器，你可能想用四阶格式发送0x9f来查看设备是否响应那个命令。
谢谢，
智



     以下为原文
  Hi Shalini,
 
Usually we want to see CS#, SCK, SI and SO together on the same wave.
 
I don't know why there is no output on SO. Did you see this on all devices? Were you able to see correct output on some other devices?
 
S25FL064L also supports the QPI mode. If that mode is set, the host is required to send the command, address, and data in 4-4-4 format. I wonder if your devices have been set to QPI. If you can modify your host controller, you may want to send 0x9F in quad format to see if the device responds to that command.
 
Thanks,
Zhi

嗨，Zhi，
我们似乎有相同的问题，如Shalini，使用S25FL064 L在基本一位宽SPI配置。设备是在原型硬件共享SCK，SI等，与其他两个设备，CY14C101P和IS25LP128。在最初的测试中，所有三个设备都在正常工作；无论如何，使用9FH操作码，我们可以始终读取正确的S25FL064 L ID。随后，我们已经使用SPI总线上的其他两个芯片开发和调试代码，但是很可能命令已经发送到U。在此期间无意中进入S25。我们现在发现，我们不能再从S25FL064 L中读取任何东西，所以它的输出在整个CS周期中保持在高Z状态。其他两个设备继续正常响应。
这似乎符合您对Shalini的建议，该设备可能已经被设置为与硬件环境不可兼容的操作模式。我们的S25’已经断电好几次了，我们已经尝试了各种命令序列，包括ABH深度睡眠唤醒，FFH模式位重置命令，以及写0h到CR1V和CR1NV，但没有任何效果。
显然，当硬件不支持时，我们不能在双数据模式或四数据模式下工作，不可能排除软件或电气故障或干扰，从而在服务中产生类似的情况。
你能建议我们检查什么，或者在一个1比特宽的硬件环境中，我们如何无条件地从这样的状态恢复S25’？
多谢。
亲切问候
鲍勃



     以下为原文
  Hi Zhi,
 
We seem to have the same issue as Shalini, using S25FL064L in basic one-bit-wide SPI configuration. Device is in prototype hardware sharing SCK, SI and SO with two other devices, CY14C101P and IS25LP128. In initial tests all three devices seemed to be working correctly; at any rate using 9Fh opcode  we could consistently read correct S25FL064L ID. Subsequently we have been developing and debugging code using the other two chips on the SPI bus, but it is quite possible that commands have beeen sent unintentionally to the S25 during this time. We now find that we can no longer read anything from the S25FL064L, the SO output of which remains in high-Z state throughout all CS# cycles. The other two devices continue to respond normally.
 
This seems consistent with your suggestion to Shalini that the device may have been set into an operating mode incompatable with its hardware environment. Our S25' has been powered-down several times and we have tried various command sequences including ABh deep sleep wakeup, FFh mode bit reset commands, and writing 00h to CR1V and CR1NV but none appear to have any effect.
 
Clearly we cannot operate in dual or quad data mode when the hardware does not support it, and it would be impossible to rule out software or electrical malfunction or interference creating a similar condition in service.
 
Can you suggest anything else we should check, or how we would unconditionally recover an S25' from such a state in a 1-bit-wide hardware environment ?
 
Many thanks.
 
Kind regards
Bob

嗨，鲍伯，
我理解。如果主机可以发送4位宽命令，那是很容易的。但是，如果您的主机只能做1位宽，这是非常困难的，但不是不可能的。
如果该设备确实处于QPI模式，则需要以4-位格式发送0xF5命令。
如果你可以手动执行这两个循环，你甚至可以非常缓慢地完成，你可以退出QPI模式，并确认这是否是问题的原因。
谢谢，
智



     以下为原文
  Hi Bob,
 
I understand. If the host can send 4-bit wide command, that is easy. However, if your host can only do 1-bit wide, it is a lot more difficult, but not impossible.
 
If the device is indeed in QPI mode, you will need to send a 0xF5 command in 4-bit format.
 

If somehow you can manually perform these two cycles, you may even do it very slowly, you may be able to exit the QPI mode and confirm if that is the cause of the problem.
 
Thanks,
Zhi

嗨，Zhi，
谢谢你的快速反应。
主机硬件不能支持4位数据。竞争
MCU引脚使用的优先级使它不可行，否则我们
可能从一开始就使用了四元模式。
遗憾的是，这个芯片上没有实现0xF5命令。
巴士宽度不可知的时尚，但我很高兴我们现在发现这个问题
而不是后来，用“砖头”设备在外地。
有趣的是，确认这个四模锁存效应是
事实上，我们的问题的原因，但不幸的是，S25’四方
在我们的硬件模式数据引脚直接连接到VCC，所以它会
可能不像你建议的那样容易。但是如果我们真的找到了
可行的，我会告诉你我们得到什么结果。
从一个实际的POV，这可能发生的事实，并在那里
我认为没有简单的1（或2）位宽的方法来恢复它。
这意味着我们必须排除S25FL064的这个和任何其他
非四边形数据应用。
亲切的问候，
鲍勃
星期一，2018年3月12日07:07:52—0700



     以下为原文
  Hi Zhi,
 
Thanks for your quick response.
 
The host hardware isn't able to support 4 bit data. Competing
priorities for MCU pinout usage made it impracticable, otherwise we
would probably have used quad mode from the start.
 
It's a pity that the 0xF5 command was not implemented on this chip in a
bus width agnostic fashion, but I'm glad we discovered this issue now
and not later, with 'bricked' equipment in the field.
 
It would  be interesting to confirm that this quad mode latch effect is
indeed the cause of our problem but unfortunately two of the S25' quad
mode data pins in our hardware are tied directly to Vcc, so it will
probably not be easy to do as you suggest. However if we do find it's
practicable I'll let you know what results we get.
 
From a practical POV the fact that this might happen, and that there
is no straightfoward 1(or 2)-bit-wide way to recover from it, I think
means that we have to rule out the S25FL064L for this and any other
non-quad-data application.
 
Kind regards,
Bob
 
 
 
 
 
On Mon, 12 Mar 2018 07:07:52 -0700

同样的问题，
S25FL040L在一位宽SPI配置突然死亡，没有任何响应从芯片，无论命令发送。在我的特定情况下，S25FL064 L与另一个存储器芯片（FM25CL64 B）共享SPI总线，该芯片没有问题。
这已经发生在我身上三次，芯片更换工作了一段时间，但后来他们继续死亡。我很高兴我发现了这个线索，因为我快要疯了，想弄清楚问题的症结所在。
我当然排除了这个组件从我们的设计现在，我希望塞浦路斯人正在寻找这个问题，以便他们可以提供一些进一步的细节。我正在尝试S25FL128L作为替代，所以会让你在循环中的情况下，这些不会产生同样的问题。
当做，
路易斯



     以下为原文
  Same issue here,
 
S25FL064L on one-bit-wide SPI configuration suddenly dies and there's no response whatsoever from the chip, no matter the command sent. In my particular case, S25FL064L is sharing the SPI bus with another memory chip (FM25CL64B) that works with no problems.
This happened to me already three times, chip replacement works for a while but then they keep dying. I am glad I found this thread as I was going nuts trying to get to the bottom of the issue.
 
I am of course ruling out this component from our designs for now and I hope CYPRESS people are looking to this issue so they can provide some further details. I am trying S25FL128L as replacement so will keep you in the loop en case these don't produce this same issue.
 
Regards,
 
Luis

嗨，路易斯，
谢谢分享信息。仅仅通过与其他设备共享SPI总线不应该导致FL128L寄存器改变其值。SPI设备只接受特定格式的命令，只要没有选择芯片，总线信号就不会对设备产生影响。
如果您怀疑确实在FL128L中设置了QPI位，那么您可能需要检查您的软件以检查WRR命令使用时的所有情况。该实现可能适用于旧设备，但不适用于FL128L，因为配置寄存器的格式是不同的。例如，如果您的软件是为FL-K设备设计的，它最终需要重新设计FL128L。您可以从相应的迁移指南中获取信息。
谢谢，
智



     以下为原文
  Hi Luis,
 
Thanks for sharing the info. Just by sharing the SPI bus with other devices should not cause the FL128L registers to change its values. SPI devices only accepts commands in specific format and as long as the chip is not selected, the bus signals have no effect on the device.
 
If you suspect that indeed the QPI bit is set in FL128L, you may want to examine your software to check all occasions when the WRR command is used. The implementation may be suitable for older devices but not for FL128L because the format of the configuration registers is different. For example, if your software is designed for FL-K devices, it definitively needs a re-design for FL128L. You can get information from the corresponding migration guide.
 
Thanks,
Zhi

嗨，Zhi，
谢谢你的快速回复。几件事：
我们正在讨论的内存芯片模型是FL064。几个线程已经指向这个问题，参照这个特定的模型。
S25FL040L NOR FLASH不响应设备ID命令
关于您关于怀疑QPI位的评论，我没有任何方法来检查，因为来自芯片的每一个响应都是“零”，正如这个线程的用户所报告的那样：
SkasRISH91Y319376:“我一直在发送这些。但是我的SO保持在地面上。“SO线只是在地面上，只有0级DC”。
BOBTGWXX3221986：“在最初的测试中，所有的三个设备似乎都工作正常[…]我们现在发现，我们不能再从S25FL064 L中读取任何东西，所以在所有CS周期中，它的输出保持在高Z状态。”
我已经检讨了我自己的司机，因为我不使用SLLD，我看不出任何机会设置四模式错误。共享总线不应该是一个问题，因为存储器使用不同的格式和双检查CS信号被正确驱动，永远不能同时启用两个存储器。有缺陷的芯片理论正在增长。
在我看来，发生这种“神奇”的改变，以四分之一模式，三个用户在不超过一个月是太多的坏运气。还有其他建议吗？
当做，
路易斯



     以下为原文
  Hi Zhi,
 
Thanks for the quick reply. Couple of things:
Memory chip model we're discussing is FL064L. Couple of threads are already pointing to this issue referring to this specific model.
S25FL064L NOR Flash not responding to device ID command
 
Regarding your comment about suspecting QPI bit is set, I do not have any way to check that as every single response from the chip is 'zero' exactly as reported from users of this thread:
shalkrish91_3193746: "I am continously sending these. But my SO remains at ground level." "The SO line is simply at ground level.0 level DC only".
BobtGWX_3219826: "In initial tests all three devices seemed to be working correctly [...] We now find that we can no longer read anything from the S25FL064L, the SO output of which remains in high-Z state throughout all CS# cycles"
 
I've reviewed my own drivers as I am not using SLLD ones, and I cannot see any chance of setting quad mode by mistake.
Sharing the bus should not be an issue as both memories use different formats and double checked CS signals are properly driven, never enabling both memories at the same time. Defective chips theory is gaining weight.
 
In my opinion, happening this "magic" change to quad mode to three users in no more than a month is too much bad luck. Any other suggestion?
 
Regards,
 
Luis

嗨，路易斯，
谢谢你对密度的修正。我知道OPN应该是FL064 L，但我的意见仍然适用，因为FL064和FL128L是在同一个家庭，但只是不同的密度。
关于你所引用的线索的问题没有结论。我不知道它与QPI位有关。
如果您阅读了我们的迁移指南注意：HTTP://wwwyCysP.COM/FIL/326361/Access，您将看到第9页关于不经意设置QPI位的警告。这不是运气，但如果在FL1-K（旧设备）上运行的软件没有改变，它会导致这种情况发生。你可以阅读AN的详细信息。
如果您想进一步调查您的问题，欢迎您发送给我一个失败的部分。然后我可以在我的平台上测试它，看看QPI位是否被设置了。
谢谢，
智



     以下为原文
  Hi Luis,
 
Thanks for the correction on the density. I understand the OPN should be FL064L, but my comments still apply because FL064L and FL128L are in the same family, but just of different densities.
 
There is no conclusion on the issues reported on the threads you quoted. I don't know it is related to the QPI bit.
 
If you read our migration guide App Note: http://www.cypress.com/file/327361/download , you will see a warning on Page 9 about inadvertently setting the QPI bit. It is not by luck, but if the software used to run on FL1-K (older device) is not changed, it can cause this to happen. You may read the AN for details.
 
If you want to further investigate your issue, you are welcome to send me one of your failed parts. Then I can test it on my platform to see if indeed the QPI bit is set.
 
Thanks,
Zhi

嗨，Zhi，
我读过你提到的应用笔记。我理解了在FL1-K迁移到FL064 L时无意中进入四路模式的可能性。
目前正在进行的设计，我正在使用FL064 L，这是一个全新的设计，因此不可能应用迁移问题。
我感谢你愿意调查失败的零件，并将他们发送到您提供的地址。
在此期间，我将尝试在我的最后模仿QAD模式不知何故，并检查是否QPI位设置。
谢谢：
路易斯



     以下为原文
  Hi Zhi,
 
I've read App Note you mentioned. I understand the possibility of going unintentionally to quad mode while migrating FL1-K to FL064L.
The design I am currently working on, on which I am using FL064L, it is a completely new design so possible migration issues are not applied.
 
I appreciate your willingness on investigating failed parts and will send couple of them to the address you provide.
In the meantime I will try at my end to emulate quad mode somehow and check if QPI bit is set.
 
Thanks :]
 
Luis

嗨，Zhi，
您引用的迁移注释很有意思。
确认如果QPI位在某种程度上被设置，则不存在。
可以在非四方硬件中重置它的机制
环境。
在设计一个真实的工业或商业环境中
接受和预期外部事件有时会引起
中断正常程序的执行和适当的预防措施
（监视器定时器等）被用来检测和恢复时
发生。这种特殊设计特征的不利影响是
而不是短暂而暂时的服务中断。
绝对最坏情况下，需要手动复位-一个坏的效果
指令字节可能是灾难性的和永久性设备故障。
对于可避免的风险来说，这是一个非常高的成本结果。
亲切的问候，
鲍勃
星期二，2018年3月27日06:47：39—0700



     以下为原文
  Hi Zhi,
 
The migration note you referenced is interesting as unambiguous
confirmation that if the QPI bit does somehow become set, there is no
mechanism by which it can be reset it in a non-quad hardware
environment.
 
In designing for a real-world industrial or commercial environment it
is accepted, and expected, that external events will sometimes cause
disruption of normal programme execution, and appropriate precautions
(watchdog timers, etc)  are taken to detect and recover when that
happens. The unfortunate effect of this particular design feature is
that instead of a brief and temporary disruption of service - or in
absolute worst-case, the need for a manual reset - the effect of one bad
instruction byte can be catastrophic and permanent equipment failure.
That's a very high cost outcome for an avoidable risk.
 
Kind regards,
Bob
 
 
 
 
 
On Tue, 27 Mar 2018 06:47:39 -0700

嗨，路易斯，
当然，你可以寄送一个样品和一个坏样品给我，只是为了比较。
我的地址是
赛普拉斯半导体公司
5204东奔白大道。MS 657
奥斯丁TX 78741。
阿特：支峰
谢谢，
智



     以下为原文
  Hi Luis,
 
Sure, you may send one working sample and one bad sample to me, just for comparison.
 
My address is
 
Cypress Semiconductor
5204 East Ben White Blvd. MS 657
Austin Tx 78741.
 
Attn: Zhi Feng
 
 
Thanks,
Zhi