You are here

S25FL256 Strange State | Cypress Semiconductor

S25FL256 Strange State

Summary: 1 Reply, Latest post by Max Willis on 10 Oct 2016 11:27 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
andrewjm's picture
10 posts

I'm using an S25FL256 with a Xilinx 7-series FPGA in single speed mode in a very simple design that works 99.9% of the time. But every once in a while something weird happens to the flash which makes our device stop working. This may occur during a power on/off but I don't know for sure

When I examine a "bad" unit I can immediately see something different from normal units--- the configuration register value is 0xEC. the configuration register value on a good unit is 0. What's more, if I try and change the configuration register value on a bad unit I get a programming error bit set and I can't talk to the memory after that. On a good unit I can change the configuration register value at will. On a bad unit I can still change the value of the status register, just not the configuration register.

The value of "0xEC" is particularly bad because it sets the latency to 0 and our software depends on the latency being 8 bits.

In our design, the "HOLD" and "WP" pins are held to Vcc.

Does anyone have any idea what could happening to our flash memories to cause the configuration register to get stuck in some strange bad value?

Any ideas would appreciated.



Max Willis's picture
Cypress Employee
1 post

Hi Andrew -

I think you are using the S25FL256S. Correct?

The issue is your system is interrupting the WRR command while it is updating the configuration register. Per AN200381 the best practice is to only use the WRR command while the system is under continuous power. Another best practice is to minimize the usage of the WRR command by always reading the register first to see if it needs changing, and then to use the WRR command only if a change is required. The best case is if you can program the configuration register once during production and to never change it again after that. 

The P_ERR programming error flag is set because your WRR command is trying to erase one or more of the OTP bits from 1 (programmed) to 0 (erased). There are two workarounds: 1) avoid the error flag by reading the current state of the OTP bits and don't try to change them from 1 to 0 using the WRR command; and 2) if the error happens use the CLSR command to clear the P_ERR and WIP flags to return the device to standby mode so that it can accept commands. There are three OTP bits, and once they are programmed to 1 they cannot be erased back to 0. 

The latency codes are non-volatile, so a WRR command can always change them back to the setting that works with your system. So if you can execute startup code while in single-IO mode, you can check the register state and correct the latency codes. 

I hope this helps!

Best Regards,

Log in to post new comments.