LittleFS writes cause crash sometimes ...

[myklemykle]

Hi, I'm having a really odd problem today. I wonder if you can tell me some way I'm using LittleFS wrong, or if there's requirements for it that i'm not following.

I have code that writes configuration data to LittleFS, and it works fine when called from one part of my main loop, but causes the MCU to crash/reboot when it's called from another location.

Here's the Settings::put() command & its components ... it's converting a struct to ArduinoJSON and then writing a JSON string to a file. It's all really basic I think. (The string is 78 bytes long.)

bool Settings::put(){

  myJDoc doc;
  _sToJDoc(s, doc);

  if (! _jDocToFile(doc, SETTINGS_PATH)) {
    return false;
  }

 return true;
}

bool Settings::_jDocToFile(myJDoc doc, char *path) {
  char buf[SETTINGS_DOCSIZE];

  if (serializeJson(doc, buf) == 0) {
    Dbg_warn("serialize to %s failed",path);
    return false;
  }

  if (! _bufToFile((uint8_t *)buf, SETTINGS_PATH, sizeof(char) * strlen(buf))+1) {
    return false;
  }

  return true;
}

bool Settings::_bufToFile(uint8_t *buf, char *path, unsigned int len){
  File f = LittleFS.open(SETTINGS_PATH, "w");
  if (!f) {
    Dbg_warn("cant write %s", path);
    return false;
  }

  if (f.write(buf, len) != len) {
    Dbg_warn("incomplete write to %s", path);
    return false;
  }

  f.close();
  return true;
}

I can call Settings::put() from my command line interpreter and it succeeds every time:

void cmd_settings(CMDARGS){
  if (strmatch(args[0].asString, "get")){
    _settings.get();
    respond("got settings");
  }else if (strmatch(args[0].asString, "put")){
    _settings.put();
    respond("put settings");   //// works every time!
  } else {
    // return the current settings
    _settings.sprint(response, MyCommandParser::MAX_RESPONSE_SIZE);
  }
}

But this call from elsewhere in the main loop, responding to a change in the state of a pin, always leads to a crash:

void handlePlayEnd(unsigned long nowTime){
  decodedPlayOnTime = decodedPlayOffTime = 0;  
  // send midi stop message:
  myMidi.clockStop();
  // flush settings:
  _settings.put();
  Dbg_println("STOP");
} 

GDB doesn't seem to be able to give me a complete backtrace when this happens, I only get this much:

isr_hardfault () at /home/earle/Arduino/hardware/pico/rp2040/pico-sdk/src/rp2_common/pico_standard_link/crt0.S:98
98	/home/earle/Arduino/hardware/pico/rp2040/pico-sdk/src/rp2_common/pico_standard_link/crt0.S: No such file or directory.
(gdb) where
#0  isr_hardfault () at /home/earle/Arduino/hardware/pico/rp2040/pico-sdk/src/rp2_common/pico_standard_link/crt0.S:98
#1  <signal handler called>
#2  0x20001d64 in rp2040 ()
#3  0x1000cea0 in lfs_dir_commitprog (lfs=<optimized out>, size=537047896, buffer=0x2002ba58, commit=0x200410e8)
    at /Volumes/External/mykle/Library/Arduino15/packages/rp2040/hardware/rp2040/3.3.0/libraries/LittleFS/src/../lib/littlefs/lfs.c:1441
#4  lfs_dir_commitprog (lfs=<optimized out>, commit=0x200410e8, buffer=0x2002ba58, size=537047896)
    at /Volumes/External/mykle/Library/Arduino15/packages/rp2040/hardware/rp2040/3.3.0/libraries/LittleFS/src/../lib/littlefs/lfs.c:1431
#5  0x0000016c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The thing I can't figure out is that this always crashes when it's called from handlePlayEnd(), but never crashes when it's called from cmd_settings(). I don't see how the two ways of calling it are any different. Are there external side-effects I should be aware of? I tried bracketing the LittleFS calles in noInterrupts()/interrupts(), it made no difference.

[earlephilhower]

W/o full code there's not much I can do, but off the bat I think there's data corruption somewhere. Nothing in this chip can have a size so big (536MB?!):

#4  lfs_dir_commitprog (lfs=<optimized out>, commit=0x200410e8, buffer=0x2002ba58, size=537047896)

General Little FS rules are not to call from an IRQ and not to multi-thread any access whatsoever (only 1 core may call any File function, etc.).

[myklemykle]

Hmm okay ... I just reduced the size of the character buffer from 1024 to 256 bytes, and now it's all working. I guess the failing call was from deeper in the call stack, with less memory remaining, so it was wrapping around the bottom of the stack.