I am using S25FL064L NAND with c6748 TI processor. I have connected
CS to CS_c6748
SO to MISO
WP not connected
VSS to ground
VCC to 3.3V
Reset not connected
SCK to SCK
SI to MOSI
I wanted to communicate to IC. I send 9f RDID command to IC. Attached is the pics. I have channel
in the figures. I am continously sending these. But my SO remains at ground level. Why does this happen? At least it should keep first 8 bytes on SO line if I get it corerect. Please make suggestion,why this does not work.
Thanks in advance
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
Attached is the SO line pic from CRO. Please suggest how to proceed. I am stuck.
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.
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 ?
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 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
On Mon, 12 Mar 2018 07:07:52 -0700
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.
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 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.
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?
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.
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.
Sure, you may send one working sample and one bad sample to me, just for comparison.
My address is
5204 East Ben White Blvd. MS 657
Austin Tx 78741.
Attn: Zhi Feng
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
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.
On Tue, 27 Mar 2018 06:47:39 -0700
I appreciate your feedback. Indeed, if the device is in QPI mode, you have to use commands in 4-4-4 format to communicate with it. However, I would not call it an equipment failure because it is not in failure mode.
I will certain forward your feedback to our design teams. Hopefully they will have a better design in the future.
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.
On Tue, 27 Mar 2018 09:30:05 -0700