SD writes but doesn't append

[thevalo]

Hardware:

Board	lilygo ttgo t-display esp32
Version/Date	ets Jun 8 2016 00:22:57
IDE name	Arduino IDE
Flash Frequency	80Mhz
PSRAM enabled	no
Upload Speed	115200
Computer OS	Windows 10

Description:

I've got a microSD module adapter from the far east, and so far so good it can create files using writeFile, but it does not append messages. It returns true, i.e: message appended successfully on the first try, but when you read the file on the computer or when ESP32 reads on reboot, it's blank. I am using two (in fact, three) SPI devices: TFT display, MFRC522, and microSD module. When working with SD operations, I disable MFRC522 and enable SD, as seen in the code blocks below.

I use writeFile if readFile returns false, that is, when the file does not exist, it invokes writeFile(SD, sdFileName, "") Specifically, when fs.open(path) of readFile returns false, I instruct to create a new file by invoking writeFile.

This is readFile, by the way:

bool readFile(fs::FS &fs, const char * path) {
  activate_SD();
  bool readSuccess = false;
  if (DEBUG == 1) {
    Serial.print("Reading file: ");
    Serial.println(path);
  }
  File file = fs.open(path);
  if (!file) {
    if (DEBUG == 1) {
      Serial.println("Failed opening the file.");
    }
    readSuccess = false;
  } else {
    readSuccess = true;
  }

  while (file.available()) {
    char c = file.read();
    fileContent += c;
  }
  file.close();
  activate_RFID();
  if (readSuccess) {
    return true;
  } else {
    return false;
  }
}

Code:

This is the suspected code that it's not doing its job, as instructed:

char* sdFileName = "/v.ea";
if (appendFile(SD, sdFileName, "Heyy")) {
//success
} else { 
//failed
}

bool appendFile(fs::FS &fs, const char * path, const char * message) {
  activate_SD();
  bool appendSuccess = false;
  if (DEBUG == 1) {
    Serial.print("Appending to file: ");
    Serial.println(path);
  }
  File file = fs.open(path, FILE_APPEND);
  if (!file) {
    appendSuccess = false;
    if (DEBUG == 1) {
      Serial.println("Failed opening the file.");
    }
  }
  if (file.print(message)) {
    appendSuccess = true;
    if (DEBUG == 1) {
      Serial.println("Appended successfully.");
    }
  } else {
    appendSuccess = false;
    if (DEBUG == 1) {
      Serial.println("Appending failed.");
    }
  }
  file.close();
  activate_RFID();
  if (appendSuccess) {
    return true;
  } else {
    return false;
  }
}

And, I use these two functions to disable/enable SD/MFRC522:

void activate_SD() {
  digitalWrite(MFRC522_SSPin, HIGH);
  digitalWrite(SDMOD_SS, LOW);
  if (DEBUG == 1) {
    Serial.println("SD is active.");
  }
}
void activate_RFID() {
  digitalWrite(SDMOD_SS, HIGH);
  digitalWrite(MFRC522_SSPin, LOW);
  if (DEBUG == 1) {
    Serial.println("RFID is active.");
  }
}

Debug Messages:

Interestingly, on the first appendFile call, it returns true and displays just this [W] level:

[W][sd_diskio.cpp:149] sdCommand(): token error [17] 0x17

However, on the second appendFile call, it returns false and displays these:

[W][sd_diskio.cpp:149] sdCommand(): token error [17] 0x17
[W][sd_diskio.cpp:149] sdCommand(): token error [17] 0x5
[W][sd_diskio.cpp:149] sdCommand(): token error [17] 0x5
[E][vfs_api.cpp:265] VFSFileImpl(): fopen(/sd/v.ea) failed

SD card space is 1GB, it is a generic brand, and its type is "SD". I've even also used appendFile but with FILE_WRITE parameter then with file.seek(EOF) but still no luck. What makes me even more, puzzled, is that the default example SD(esp32) works well: creating files, appending, deleting, renaming, etc. Therefore I suspect the problem is seeded hidden in my logic somewhere.

[me-no-dev]

logic looks fine. the only thing that I see is that you should not try to print/close the file if it had failed to open. Apart from that, I recently introduced some fixes in the SD class and will be happy if you can give them a shot

[thevalo]

you should not try to print/close the file if it had failed to open

Thanks! Will re-formulate the logic.

I've actually found the problem, but no solution:
it's the rfc.init() which is causing the problem. If I initialize the MRFC522 object, the SD fails to append but reads fine. However, when I don't initialize its object, the SD operations (including append) work just fine. I've also tried to initialize SD before MRFC522, but no luck. As I said, I'm using two SPI with a 330Ohm resistor between MISO and microSD adapter module.

Will try the new PR (#4876) soon and let you know.

[thevalo]

Hmm, I've updated SD (cpp, h), sd_defines.h and sd_diskio.h but Arduino IDE compiler reports this and doesn't compile:

libraries\SD\SD.cpp.o:(.literal._ZN2fs4SDFS5beginEhR8SPIClassjPKchb+0x0): undefined reference to `sdcard_init(unsigned char, SPIClass*, int)'
libraries\SD\SD.cpp.o:(.literal._ZN2fs4SDFS5beginEhR8SPIClassjPKchb+0x4): undefined reference to `sdcard_mount(unsigned char, char const*, unsigned char, bool)'
libraries\SD\SD.cpp.o:(.literal._ZN2fs4SDFS5beginEhR8SPIClassjPKchb+0x8): undefined reference to `sdcard_unmount(unsigned char)'
libraries\SD\SD.cpp.o:(.literal._ZN2fs4SDFS5beginEhR8SPIClassjPKchb+0xc): undefined reference to `sdcard_uninit(unsigned char)'
libraries\SD\SD.cpp.o:(.literal._ZN2fs4SDFS8cardTypeEv+0x0): undefined reference to `sdcard_type(unsigned char)'
libraries\SD\SD.cpp.o:(.literal._ZN2fs4SDFS8cardSizeEv+0x0): undefined reference to `sdcard_num_sectors(unsigned char)'
libraries\SD\SD.cpp.o:(.literal._ZN2fs4SDFS8cardSizeEv+0x4): undefined reference to `sdcard_sector_size(unsigned char)'
libraries\SD\SD.cpp.o: In function `fs::SDFS::begin(unsigned char, SPIClass&, unsigned int, char const*, unsigned char, bool)':

A problem on my side, or somewhere else?

[me-no-dev]

on your side. seems sd_diskio.cpp did not compile?

[me-no-dev]

could it be that MRFC522 is holding the MISO line in some way? Also, you should not control the SDCard's SS line yourself. That is done by the library

[thevalo]

on your side. seems sd_diskio.cpp did not compile?

Yep, thanks! It seems like sd_diskio.cpp wasn't there at all. Don't know how it went missing.

could it be that MRFC522 is holding the MISO line in some way?

I'm suspecting about this too. How would I confirm/resolve this issue, if it is the case?

Also, you should not control the SDCard's SS line yourself. That is done by the library

Hmm, alright. I will try SD.begin() without any parameter.

[me-no-dev]

SD.begin without parameter will use the default SS pin. this is not what I said :) just do not control it through your code.

[thevalo]

Alright, so you mean I shouldn't use the two functions (activate_RFID/activate_SD) and leave them on their own?
BTW, just updated the esp32 library to 1.0.5 and I'll replace existing SD files with the newest one from the aforementioned PR.

[me-no-dev]

so you mean I shouldn't use the two functions (activate_RFID/activate_SD) and leave them on their own?

yes :)

[thevalo]

As stranger as it gets! Updated the esp32 board to 1.0.5, replaced existing SD files with your PR, now here's what appears:

[E][esp32-hal-cpu.c:93] addApbChangeCallback(): duplicate func=400E325C arg=3FFBDE14
[W][sd_diskio.cpp:170] sdCommand(): no token received
[W][sd_diskio.cpp:170] sdCommand(): no token received
[E][sd_diskio.cpp:195] sdCommand(): Card Failed! cmd: 0x00
[W][sd_diskio.cpp:506] ff_sd_initialize(): GO_IDLE_STATE failed
[E][sd_diskio.cpp:776] sdcard_mount(): f_mount failed: (3) The physical drive cannot work
[W][sd_diskio.cpp:170] sdCommand(): no token received
[W][sd_diskio.cpp:170] sdCommand(): no token received
[W][sd_diskio.cpp:170] sdCommand(): no token received
[E][sd_diskio.cpp:195] sdCommand(): Card Failed! cmd: 0x00

[thevalo]

I can confirm that the above error appears only when I'm using my sketch. Using SD(esp32) example from sketches, work fine!

[thevalo]

Just put SD.begin() immediately after SPI.begin (it was TFT, mfrc then SD) and now the SD errors above don't appear anymore! Except for the addApbChangeCallback(): duplicate.

Though MFRC522 reports Firmware version v2.0, it doesn't work. I started to suspect that the microSD module is not releasing MISO properly?

[me-no-dev]

one of the two is definitely the reason. What if you remove the resistors on MISO? SD + something else on the same bus is quite common thing

[thevalo]

If I remove the resistor on MISO, the MFRC prints:
Firmware Version: 0xE1 = (unknown)
and it doesn't work, again.

Tried to also switch places of MISO: SD Card - Resistor - MISO+MFRC522 also MFRC522 - Resistor - MISO+SD Card but it's the same, 0xE1.

P.S.: I've also noticed that [E][esp32-hal-cpu.c:93] addApbChangeCallback(): duplicate func=400E325C arg=3FFBDE14 appears after calling MFRC522 functions (PCD Init, dump version to serial). Weird enough, this didn't happen before updating esp32 board library to 1.0.5. I think this is what causing it not to work.

[me-no-dev]

which slave are you initializing first? Try to switch them around and do not forget to power-off the board completely before retry

[thevalo]

I think I've found the problem, I mean, obviously, but:
I usually initialized TFT graphics: tft.init(); then MFRC then SD card. By controlling manually the SS of the MFRC/SD card, it worked partially, just not appending. As I've explained in the very first post. Board version 1.0.4.

I've just updated esp32 to 1.0.5, and MFRC refuses to work, even if it reports firmware version v2.0. The TFT's MOSI is connected to another pin (19). If I try the same thing but with 1.0.4, it works fine. So, not initializing tft, MFRC522 works fine in 1.0.4 but not in 1.0.5.

I've also disconnected the SD card module completely, just to be sure there aren't any hardware-connection faults. They work fine on their own, but not when connected together via SPI (TFT, MFRC, SD).
I'm scratching my head now to figure out how to init and "un"-initialize each one when I'm performing operations with them.

Also, should I use mfrc PCD_SoftPowerUp() before PCD_init()?

Here's the board pinout diagram, by the way:

[thevalo]

So, with 1.0.5 I've managed to make SD card and TFT work, but not MFRC522.
By using 1.0.4, the TFT and MFRC522 worked, but not the SD card module. Indeed strange.

Edit: I started to suspect that it's a loose wire connection, being the culprit of why sometimes works with different versions (1.0.4/1.0.5) and sometimes not. This may or may not explain even why the SD card fails to append. I will update once I confirm this.

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.