Arduino reseting when connected to SD card and battery charger

Hi, I am building a PCB to use a Nano ESP32 with a SD Card. The board is powered by a 1S LiPo 3.7V battery. I am using a LM3671 to regulate 3.3V and supply to the Nano board via 3.3V pin - I know, I am powering the output of the MP2322, which is not ideal. I also use a MCP73831 to charge the battery. I didn't cut the 3.3V pad at the bottom of the board, because I still want to upload sketches using USB. Instead, I included a dip switch that removes the 3.3V when I am programing the board.

Everything works great, unless I try to run the board while the battery is being charged at the same time. In this case, the Nano keep reseting. If I remove the SD card out of its slot, it works fine again. Attached is the schematics of my setup. Am I missing something here?

@Piscold
You're really not supposed to use it that way.
The MP2322 provides proper powering for all the stuff that is on 3V3 on the Nano, including the Flash.
Your circuit is not guaranteed to do the same.
It's always advised to power Nano boards from VIN or USB, and with modern boards which have all this extra hardware this is even more enforced.
It seems that your SD Card is introducing some sort of additional draw which makes the chip brown-out.
I think it's probably due to the additional circuitry around the MP2322.

Maybe you could try and cut the pad SJ1 under the board, which cuts out the MP2322 from the rest of the circuit

@ubidefeo, thanks! I am building one with the 3.3V cut. It is a shame that pad is under the board, so, after I install the board, I can't upload sketches anymore... (can I upload if I power the board with 3.3V???), but, I will give it a try.

It is interesting that I have some of these boards made and some of them don't show the problem at all, some are intermittent, some only do when connect to the charger, and one does all the time, with charger or not...

Again, thanks for your input!

So, I tried with the 3.3V pad cut. Good news is that I can still upload sketches if I power the board while connected to the USB (different from what this page says - Nano Boards that can be powered with 3.3V.

The board doesn't reset by itself, which is also good, but I still have problems reading the SD card while charging the battery. It initialize the SD card, because it pass this part of my code:

  Serial.print("Initializing SD card...");
  // see if the card is present and can be initialized:
  if (!SD.begin(chipSelect)) {
    Serial.println("Card failed, or not present");
    while (true) {
      currentMillis = millis();
      if (currentMillis - previousMillis >= error_interval) {
        previousMillis = currentMillis;
        if (ledState3 == LOW) {
          ledState3 = HIGH;
        } else {
          ledState3 = LOW;
        }
      }
      digitalWrite(ledPin3, ledState3);
    }
  }

It reads a file in the card, and display on the serial monitor information from the file:

if (SD.exists("/CONFIG.txt")) {
    set_config("/CONFIG.txt");
  }

But when I look for my datafiles to find the last files and create a new one with an incremental number, it fails, always returning file data000.dat:

  int n = 0;
  snprintf(data_filename, sizeof(data_filename), "/data%03d.dat", n);  // includes a three-digit sequence number in the file name
  while (SD.exists(data_filename)) {
    n++;
    snprintf(data_filename, sizeof(data_filename), "/data%03d.dat", n);
  }
  dataFile = SD.open(data_filename, FILE_READ);
  Serial.print("New file created: ");
  Serial.println(data_filename);
  dataFile.close();
  dataFile = SD.open(data_filename, FILE_WRITE);

This makes me think... Am I asking something from the SD card on this last code that is wrong? It seems that before I cut the 3.3V pad, this was also the point on my code that made the Nano reset...

Trying to help is a pleasure, there's always something to help :slight_smile:

I have little experience with SD cards, but one thing I have learned is that you need to sloooooooow down if you want things to work.
Multiple consecutive read operations may yield failure more often that you think.
It might be that the while in which you test for the presence of a certain file happens too fast, or that the files created have a different file name :thinking:

I see you using snprintf so the \0 is appended to the file name, padding in string format looks correct.
Can you check whether creation of the files actually happen?
Try to run a simple sketch which creates 20 files and then bring the SD to a computer to see