Problems with SD file operations (writing)

Hello,

Is it possible that the SD I/O libraries for the Sakura have a bug for writing right now? It seems that we only get files filled with wrong characters and even corrupt files at the moment.

The codes for writing in our specific case have not been changed, but the output is changed dramatically. (as of 9-1-2018 for as far as we know)

 

-美月

  • Hi Mitsuki,

    Were you able to resolve the issue already? Please wait a little bit more until someone can confirm about your doubt on the Sakura SD I/O library. Thanks for understanding.

    JB
    RenesasRulz Forum Moderator
  • Hello JB,

    No luck yet, the issue is still present. I will wait until someone can confirm about the libraries. Meanwhile I will try to resolve it myself, too.


    -美月
  • Hello JB,

    I have since uploaded the example program and that one gives problems too. It can be read by the Sakura before it is close();'d, but after that I can't read it back on PC. Is it perhaps known whether there are demands for certain cluster sizes, SD card sizes or anything? I do know about the 8.3 names requirement.

    As for saving within my project, does it give problems if I first manually SD.flush(); and then SD.close();, since SD.close(); flushes as well? The reference does not mention anything about it not being allowed.

    Quick update: I just removed the SD.flush(); attempt to make it work and it stillproduces a file that cannot be opened on a PC. This also means that the file is not read by the Sakura. 


    -美月

  • Hello JB,

    In my last message I told that I tried the demo program and that the data in it cant be read back on a PC (which is a requirement, by the way). I have since tried some more things, and at the moment I can write a file ..sometimes. When I try opening a file, it will not always do it. Generally, from the 2nd attempt on it will succesfully open a file for writing. Once, it worked the first time, but it produced a file of nearly 4GB, that was 0B when I tried to delete it.

    I will post my piece of code below. Note that I changed variable names.

     

    if (SD.exists("filename.txt") && !xOnlyDeleteOnce){ 
    SD.remove("filename.txt");
    xOnlyDeleteOnce = true;
    }

    fileVar = SD.open("filename.txt", FILE_WRITE);

    if (fileVar) {
    fileVar.print(intVar1);
    delay(5);
    fileVar.print(",");
    delay(5);
    fileVar.print(intVar2);
    delay(5);
    fileVar.print(",");
    delay(5);
    fileVar.print(intVar3);
    delay(5);
    fileVar.print(",");
    delay(5);
    fileVar.print(intVar4);
    delay(5);
    fileVar.print(",");
    delay(5);
    fileVar.print(intVar5);
    delay(5);
    fileVar.print(",");
    delay(5);
    fileVar.print(intVar6);
    delay(5);
    fileVar.print(",");
    delay(5);
    fileVar.print(floatVar1, 2); // print two decimal places
    delay(5);
    fileVar.print(",");
    delay(5);
    fileVar.print(floatVar2, 2); // print two decimal places
    delay(5);
    fileVar.println(","); // Ends line and inserts cr/lf
    delay(5);
    delay(300); //@TODO test this -> didn't work
    fileVar.close();
    Serial.println("Done writing!");
    }
    else {
    errorFlag = true;
    errorCode = 11;
    }

    // This is followed by 

    if (!fileVar) { //code to return to main scenario }

    I hope that you, or anyone else, can help me fix this problem

    -美月

  • Solved the problem by adding a 1 second delay before starting to write. It writes normally now, without any errors, and the files can be read back from a PC. I guess the MCU was still busy and thus things went wrong when it tried to write to the SPI bus.

    -美月
  • ,

    And just when I thought it all worked again, it starts to misbehave. i "solved" my problems by adding delays, suspecting the Sakura was still busy updating registers when it got the SPI requests. It all went very well, until yesterday. Now, the Sakura starts to delete random files from the SD card, even files I am not touching. The only change I have made is that I have inserted tabs in my printed text, as follows
    fileVar.print("\t\ttabbed text\t\tnext field");
    One would assume this is a valid operation that does not remove random files.

    Also, is it possible to do something equivalent to "safely remove hardware" in Windows, for example before I shut the MCU down? I know it is supposed to not be needed for FAT16, but a corrupt filesystem would explain this strange behaviour.

    -美月
  • I'm sorry for no response to this forum. I would like to try your condition. Could you let me know the version or the development environment. The current version of libraries is V2.20. Do you use web compiler or e2studio project?
  • Dear Okamiya Yuuki-san,

    I am currently using e2studio. Could you tell me where I can find the library version?

    -美月
  • Ok. There is no description in libraries. The version is only described template name or default sketch as below.

    If you could, try the latest version V2.20 downloadable at GR-SAKURA web. http://gadget.renesas.com/en/product/sakura.html

    Note that the projects can be used with e2studio V5.4, not for V6.x.

  • Dear Okamiya Yuuki-san,

    I just tried using that sketch, but it does not want to work at all. Even the sketch.cpp gives errors. Inserting my files gives errors in that it can't find anything. (header files mostly)
    I am using e2studio version 5.4 already, so that can't be the problem.
    The SD library was not changed between my version and the new one, with the only exception being that GRSAKURA is now __RX600__; not a functional change.

    The SD card problems have been "fixed" in my old project again by increasing the delay I put after my fileVar.close(), as follows
    delay(100); // shorter delays might result in the file not opening. RX63 still busy changing registers maybe?
    File fileVar = SD.open("filename.ext", FILE_WRITE);
    fileVar.print("someText\t\tnext Field\nfirstEntry\t\tsecondEntry");
    fileVar.close();
    delay(100); // 50ms is too little, 100ms feels sluggish.

    Even though delays work, it does make the entire device feel sluggish (you have to wait till the delays and writing is done before the next screen appears and you can continue). It would be really nice if I could get rid of those delays in some ways. Do you have any advice as for how I can accomplish this?

    -美月