Write Enable command to S25FL512S occasionally ignored

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

cross mob
miri_3550856
Level 1
Level 1

I'm talking to an S25FL512S from an Atmel SAM4e on SPI bus running at 50MHz.  (No quad spi or anything clever like that.)

I'm testing some firmware I have for writing to flash.  My test reads and writes the flash constantly.  During this process, the flash is repeatedly accessed in the  following sequence:

1. Read page X

2. Write back to the same page X,

3. Read back page X to verify write.

4. Write page Y.

5. Read page X

6. Write to page X

7. Read back page X to verify write.

Done

In this way I move through the pages of 2 blocks of flash.  I'm only running the tests on two blocks.  I'm only testing on one flash chip, though my board has 4. 

Before Read and Before Writes I check the Status Register #1 (SR1) to make sure the Write In Progress (WIP) bit = 0.

Once I've verified the WIP bit, if the job is a write, I send the Write Enable command then I read the Status Register to verify the Write Enable Latch is set.  Every once in a while I find that the WEL bit is NOT set.  I observed this failure connected with the writes in step 2, 4, and 6. 

I tried waiting around and checking over and over again, but the WEL bit never changed.  This implies the Write Command failed to reach or was not accepted by the chip. 

I started sending the Write Enable command a second time, if the first time fails.  This solves the symptom.  So far, I've never had to send the write enable command more than twice to get it to stick. 

I looked for signs that there might be an error on the Spi bus - a timeout or something that I neglected to trap, but I can't find any evidence of this.  One of the things I looked at was the effect of a SPI clock speed change.  I ran a test at 50MHz and one at 30MHz.  At 50MHz I averaged an error every 14 seconds.  At 30MHz I averaged an error every 8 seconds. 


I looked for signs that other commands to the flash were failing - but I can't find any.  Interestingly the readback stage (step 2 & 7 in the process above) always succeeds so long as I was able to get the WEL set.  If I had a hardware problem, I would expect my actual write command and my read command to fail occasionally.

I've been scouring the data sheet, looking for circumstances under which the S25 would reject the WREN and I'm coming up blank. 

Next I'll test at a lower level, getting more and more of my own firmware out of the way to try to find the offending layer.  But I am wondering if I'm possibly violating some rule to do with the S25.  I haven't work with this family before. 

.

0 Likes
4 Replies
SudheeshK
Moderator
Moderator
Moderator
250 sign-ins First question asked 750 replies posted

Hi,

Could you please provide oscilloscope waveform for Read and WREN commands (for failing condition)?

Please make sure you follow tCS (CS# high time) timing spec in your application.

Thanks and Regards,

Sudheesh

Hello Sudeesh, Thank you so much for your suggestion!!!

I've hooked up my scope and am watching the CS pin.  I've set up the trigger to look for a positive pulse on the CS pin that is <= 50ns.  The spec says I need 50ns of CS = 1 following a write and 10ns following a read.  I'm using the specs for "SPI Single Bit" and Vcc = 2.7 to 3.6V.

Meanwhile, as my test cycles through 2 blocks of the flash, the program's debug output prints to the screen when the error is trapped.  So the firmware tells me if there is a failure to enable write on the flash.  The firmware then sends the write enable command again.  As I mentioned above, the second write enable always takes, but just in case, the firmware will report an additional error if the second write enable fails.

With the pulse width trigger selector set to 50ns, I dont get any triggers, though I see the firmware trapping the write enable error on the firmware's debug output.

When I adjust the selector up to around 240us, I get triggers.  Adjusting the selector down to 150us, no triggers.  So my chip select is always high at least 150us, well over the 50ns requirements of the data sheet.

Last night I stripped off some fw layers and ran a test that involved only the component driver and the spi interface layers.  The error is still there.  So I feel confident the problem is not in my file system firmware.

I took a look at other signal timing requirements this afternoon.  I seem to be in spec.  Having said that, my scope and probes aren't truly up to the task of 50MHz - so I'm looking at triangles and making educated guesses about whether my edges are too close.  I work from home -- all the good equipment is in the main office. 

0 Likes

Hi,

Sorry for the delay. Did you try to test other flash devices on your board? Are you observing this same issue with them also?

Thanks and Regards,

Sudheesh

0 Likes

Thank you for getting back to me.  I *think* I've tested this with multiple chips, but I'll do again to make sure. 

0 Likes