ESP8266 Community Forum

- Thu Dec 31, 2015 8:12 pm #37591 Hello iggr / itay,

First, I am very new to ESP and can easily get lost.
I have exactly the same issue on Wemos D1 board(Even with different code when not using SPIFFS but I am pretty sure that the issue started after I first tried to deploy an example which uses SPIFFS) I was thinking that erasing the chip would fix the issue, too.
I tried with 2 different firmware versions. Now, when the board tries to connect to the SSID, the board resets with wdt reset.

Can you please share more details on how to erase the chip? which tool to use, which firmware version and any specific parameters to do a complete erase (In my case after the firmware update board somehow remembered the SSIDs)

Thanks in advance,
Ozan

- Wed Jan 27, 2016 10:42 am #39826 Having a similar problem when trying to open a file for writing, erasing apparently didn't help. Any ideas on what I might be doing wrong or what else to troubleshoot?

The module:
ESP8266-07
REST - high
CH_PH - high
GPIO15 - low
GPIO0 - high when running, low when flashing
Power supply voltage - sufficient, checked

The code:

1. In setup():

Code: Select all  if (persistenceEnabled) {
    if (!SPIFFS.begin()) {
      persistenceEnabled = 0;
      Serial.printf("Failed to open file system\n");
    } else {
      Serial.printf("File system initialized\n");
    }
  }

2. In loop():

Code: Select all      Serial.printf("Opening %s...\n", SEQ_FILE_NAME);
      File seqFile = SPIFFS.open(SEQ_FILE_NAME, "w");
      if (seqFile) {
        Serial.printf("Writing file %s\n", SEQ_FILE_NAME);

Erase:

1. Power on in flashing mode.
2. ./esptool.py --port /dev/ttyUSB0 --baud 115200 flash_id
Connecting...
Manufacturer: e0
Device: 4014
3. Proves the connectin is working.
4. Power off & on, connect in flashing mode again.
5. ./esptool.py --port /dev/ttyUSB0 --baud 115200 erase_flash
Connecting...
6. There is no confirmation of success, by design:

Code: Select all    def flash_erase(self):
        # Trick ROM to initialize SFlash
        self.flash_begin(0, 0)

        # This is hacky: we don't have a custom stub, instead we trick
        # the bootloader to jump to the SPIEraseChip() routine and then halt/crash
        # when it tries to boot an unconfigured system.
        self.mem_begin(0,0,0,0x40100000)
        self.mem_finish(0x40004984)

        # Yup - there's no good way to detect if we succeeded.
        # It it on the other hand unlikely to fail.

Run the code:

Code: Select allFile system initialized
...
Opening /seq.dat...

 ets Jan  8 2013,rst cause:4, boot mode:(1,6)

wdt reset


- Mon Feb 08, 2016 10:08 am #40708 By the way it looks in serial console, it looks like a call to SPIFFS.open(SEQ_FILE_NAME, "w") does not return for 2-3 seconds and the whole thing gets reset by watchdog. If only I knew what takes SPIFFS so long...

- Mon Feb 08, 2016 12:04 pm #40715 Finally, problem solved. Briefly: 1) SPIFFS is fine 2) pointers are evil. A function I was calling before write was using pointers and apparently was screwing up SPIFFS memory.

Troubleshooting

1. Add a function like this:

Code: Select allvoid writeTest() {
  Serial.printf("Pre Write test %u\n", SPIFFS.exists("/test.txt"));
  File f = SPIFFS.open("/test.txt", "w");
  if (f) {
    f.print("test");
    f.close();
    Serial.printf("Write test ok %u\n", SPIFFS.exists("/test.txt"));
  } else {
    Serial.printf("Cannot write file\n");
  }
}


2. Insert a call to it in setup() just after you do SPIFFS.begin(), check it works, start moving it down the code until you reach the place where it breaks.

3. Look for the offender shortly before, paying attention to any pointer operations.