S25FL064L NAND flash not returning data for RDID command

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

    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

1-SI

2-SCLK

3-CS

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

With Regards

Shalini

scope_0.png

scope_1.png

tcope_0.png

vcope_0.png

0 Likes
19 Replies
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

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

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

Hello,

Attached is the SO line pic from CRO. Please suggest how to proceed. I am stuck.

With Regards

Shalini

so_signal.png

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

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

0 Likes
Anonymous
Not applicable

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

ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

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.

pastedImage_0.png

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

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

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

0 Likes
Anonymous
Not applicable

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

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

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

Anonymous
Not applicable

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

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

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

0 Likes
Anonymous
Not applicable

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

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi Bob,

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.

Best regards,

Zhi

0 Likes
Anonymous
Not applicable

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

0 Likes
ML_in_Ca
Level 1
Level 1
First reply posted Welcome!

This is very unfortunate. I wish this had been emphasized/highlighted in the datasheet, and we would not have used this device. Now we have equipment with the flash ram out in the field where, in rare instances, brown-outs may happen which can invoke QPI. You should ALWAYS be able to wake up a device in its basic mode via a simple reset mechanism. We are now stuck with having to return failed equipment and physically replace the device. Not pretty!

Infinium: Please add a paragraph ASAP to your datasheet, and in bold!

0 Likes
ML_in_Ca
Level 1
Level 1
First reply posted Welcome!

... OK, so if you always issue a QPIEX command (0xF5) in QPI mode as the very first instruction upon startup, then a subsequent generic Jedec RDID will always succeed. It appears the QPIEX command is benign to older flash devices, so your system will remain backward compatible and without side effects.

As for submitting the QPIEX command; the host uP should at minimum have access to SI, SO, & RST, while WP might be tied to VDD. The two nipple command is:

1) {RESET#, WP#, SO, SI}  = 0xF

2) {RESET#, WP#, SO, SI}  = 0x5

Thus, WP# remains 1 for both commands. What luck. The rest can be done by manually controller each bit, including CK.

0 Likes
ML_in_Ca
Level 1
Level 1
First reply posted Welcome!

We have received one device back from the field and cannot wake it up and/or read its ID.

Note; our initialization software will now force a QPI exit upon power-up. We have tested the QPI exit with other devices where we force the device into QPI mode. Once in QPI mode we can no longer access the device. A system reset/reboot is issued, and the device recovers during the initialization QPI exit - after which normal operation resumes.

However, the device we received from the field has gone AWOL. Our system experienced no recorded stress or other unusual events. Is there a way we can return the device to Infineon for evaluation?

0 Likes