Issues with SPIFlash and Spansion S25FL128L memory

Status
Not open for further replies.

CompuCat

Member
Hello all! I'm having issues with the SPIFlash library behaving weirdly with a Spansion S25FL128L SPI flash chip. Running EraseEverything seems to work, but it finishes in 0 seconds, which seems abnormal. Not sure if the erase is successful or not. Also, RawHardwareTest continuously fails at the same address with the following message, even after running EraseEverything beforehand:

Code:
  Previous data found at address 7864320
  You must fully erase the chip before this test
  found this: 00 00 00 00 00 00 00 00 
    correct: 00 78 00 00 2D 62 78 FC

The memory and block sizes are detected correctly. Both sketches are identical to the stock examples; however, I removed the id2chip function in RawHardwareTest and all references to it, as it was eating up too much RAM on an Arduino Uno. (RawHardwareTest would end up running out of RAM and crashing.)

Hardware setup: Arduino Uno through hardware SPI and 5v-3.3v level shifters to the Spansion flash memory. That's it.

Can anybody verify these results or offer any advice? Thanks!


EDIT: I attempted another full erase-test cycle, and the erase seems to be successful, but I repeatedly have errors while trying to write the signatures. It's at the same address every time...bad silicon?
 
Last edited:
Haven't used the Uno in awhile, but in my experience EraseEverything is always slow on every flash chip I've used, so if it is fast I would assume that it is not executing.

I would start there -- if you cannot completely erase the chip, nothing else is going to work correctly or add more information.

Serial print debug statements added to the library can tell you at what software point the erase process is not succeeding.

I'd also measure voltages and scope the signal lines.

gl!
 
Yeah, I suspected the same. Having said that, RawHardwareTest doesn't find any previous data if I let EraseEverything run for a good 45 seconds (predicted time: 34 seconds IIRC) after it claims it finishes, which leads me to believe that there's an issue with SerialFlash.ready(). I'll test it once I get back to the hardware. My voltage rails are fine (first thing I checked), and the same signal lines work fine with other SPI devices also hooked up on the bus at full speed. I don't have a scope, but I'll try running a few tests to double check that other SPI devices on the bus aren't interfering with the flash.

Good point on the debug statements within the library itself-I'll make a separate copy of the library to prevent myself from accidentally changing the master and forgetting to revert my changes. I'll post back once I've gotten some results. Thanks!
 
Update: after some debugging, EraseEverything seems to be working as intended. I can't find any issues with it; it's completing correctly. The impossibly fast time appears to be caused by the flash clearing the "busy" bit in the status register; that's correct behavior, but it's doing it much, much faster than expected. Write testing in RawHardwareTest continues to fail at the same location every time. The failure mode is quite consistent; as such, I don't think the issue is due to noise or some sort of random error. At this point, I'm highly suspicious of bad silicon, though it's quite unlikely. I can't think of any other explanation for this.
 
You may have already done this, but here's what I would do next with RawHardwareTest:

Uncomment the serial.print statements and comment out the whole create_signature and short-circuited return from the test block, and just let it show you what's on the entire chip.

Code:
  while (address < chipsize) {
    SerialFlash.read(address, buf, 8);
    Serial.print("  addr = ");
    Serial.print(address, HEX);
    Serial.print(", data = ");
    printbuf(buf, 8);
//    create_signature(address, sig);
//    if (is_erased(buf, 8) == false) {
//      if (equal_signatures(buf, sig) == false) {
//        Serial.print("  Previous data found at address ");
//        Serial.println(address);
//        Serial.println("  You must fully erase the chip before this test");
//        Serial.print("  found this: ");
//        printbuf(buf, 8);
//        Serial.print("     correct: ");
//        printbuf(sig, 8);
//        return false;
//      }
//    } else {
//      count = count + 1; // number of blank signatures
//    }
    if (first) {
      address = address + (testIncrement - 8);
      first = false;
    } else {
      address = address + 8;
      first = true;
    }
  }

If the chip was actually erased, all the addresses should contain 0xFF. The failure message you posted shows values of 0X00, which makes me believe you are not able to erase the chip in the first place. If some of the chip contains 0xFF but one address area contains 0x00, then you *may* have a bad chip, or perhaps the erasure failed completely but the chip already contained some 0xFF values. If none of the chip was erased to 0xFF, then I think there could be a problem with your setup.

The next step would be to uncomment the code that writes a hash signature and verifies it, while leaving serial print statements enabled (both before and after the write) to show how many successful writes and reads there were before the bad one. I'd still comment out the short-circuit, so it would go through the entire chip even if it found an error.

Not sure if this will help, but it's a cheap next step :cool:
 
Last edited:
Aha, thanks! I was having a bit of trouble figuring out exactly what/where to modify in RawHardwareTest to just show raw chip values. I was under the impression that erased flash memory would be all 0x00's, not 0xFF's, that explains a lot! I'll do some more testing once I can get back to the hardware.
 
Hey, I found that onehorse got the exact same error as you when using RawHardwareTest on known good chips of the same type as yours. A modified code library worked correctly.

I *think* these issues should have been addressed in more recent versions of the library, so perhaps you should double-check, or just blow it up and reinstall the latest arduino IDE and teensyduino.

Here's the thread link:
https://forum.pjrc.com/threads/27698-Memory-board-add-on-requirements/page7

There's also some indication that you may need pull-up resistors or to activate internal pullups with code like this:

Code:
https://forum.pjrc.com/threads/27698-Memory-board-add-on-requirements/page7
 
Oh nice! Not sure how I missed that on my initial search. I'll try that modified library if nothing else works; I'm running the latest version of the library from GitHub. Communication of JEDEC ID, etc. works fine, so I don't think pullups are required (something's already activating them).


EDIT: just tested the chip. It appears that erases are successful....?!?!?!?! Nothing but 0xFF in sight, and this is after one of those impossibly quick erases.
 
Last edited:
I ordered one of these chips for testing.

No idea when (of if) I'll get around to actually working with it... but one is on the way here.
 
Hey there, thanks so much Paul!

I haven't had much time to test the flash recently (other portions of my project's design have been prioritized), but I'll test the modified library CraigF mentioned as soon as I can. Curious, do you remember what it does differently from the stock library?
 
Status
Not open for further replies.
Back
Top