Can you also show the SO line on your waveforms? We don't know if it returns a value or not.
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
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