SD errorCode: 0X30,0XFF

Using Arduino Storage
1

Getting SD errorCode: 0X30,0XFF when trying to open SdBaseFile configFile.open("config.txt", O_READ)

Using SdFat library. Tried versions 1.0.3 and the later 1.1.2 with the same results.

It was working fine for a couple of days and then suddenly quit with the above error happening rather consistently. I'm using TXB0104 for level shifting.

Can anyone shed some light on what the error code means?

How can I debug further?

With no microSD inserted, sd.begin(SD_CS_PIN, SPI_FULL_SPEED) never returns.

Any help is appreciated.

2

Which Arduino board are you using?
Is this with your sketch? If so, did you try with one of the example sketches.Have you tried another card?

Far outside my knowledge, but 0x30 might indicate (from SdInfo.h)

  SD_CARD_ERROR_CMD17 = 0X30,

Which is used in SdSpiCard.cpp as below

bool SdSpiCard::readBlock(uint32_t blockNumber, uint8_t* dst) {
  SD_TRACE("RB", blockNumber);
  // use address if not SDHC card
  if (type() != SD_CARD_TYPE_SDHC) {
    blockNumber <<= 9;
  }
  if (cardCommand(CMD17, blockNumber)) {
    error(SD_CARD_ERROR_CMD17);
    goto fail;
  }
  if (!readData(dst, 512)) {
    goto fail;
  }
  spiStop();
  return true;

fail:
  spiStop();
  return false;
}
3

Thank you for your reply.

I've soldered the ATmega328P-MMH to a breakout board and wired all the connections.

It is my sketch. However, it had been working for some time and then suddenly broke.

I have tried couple of other cards and they work in a similar ATmega328P-AU based system.

I did see where it fails trying the CMD17. However, I don't know what might be possibly wrong when CMD17 fails. One obvious reason could be bad SD card but I have ruled out that possibility. I've visually inspected all the connections and checked for continuity but it all looks good.

What could be the next place I should look?

4

Did you solder the card directly to your board? Or did you use an adapter so you can replace cards.

In the latter case, did you try another card?
Did you try simple test code from the library examples?

5

My system is part of a larger system connected to an ESP and communicates with ESP via MinimumSerial. There is no appropriate example that will fit the scenario unless I'm missing something (please point to an example in that case).

I have a similar system that has actually worked for years that is using 74HC4050 as voltage level shifters. I have now designed a new system that uses bi-directional voltage level shifters using TXB0104. It worked nicely for couple of days when one day it suddenly stopped reading files on the microSD (if inserted) or won't even return from call to SD.begin(CS_PIN) if no card is inserted.

I'm able to upload new sketches using 'Arduino as ISP' using the same lines as microSD except only one device is connected at a time. The sketch is supposed to read data from the microSD and return it back to ESP over SoftwareSerial based on reading a command from ESP.

It's a fairly complex system (at least to me) and I didn't want to go through replacing each component or rewiring everything (I just did that once because of some other issue).

I was hoping to be able to debug more such that I'm able to narrow down what might be the issue so that I can start there.

Thanks for keeping up with me.

P.S. - I'm able to swap cards and tried a few that work in the old system without issues.

6

Did they also fail in the new system? If so, did they keep on working after placing them back in the older system?

My thought is to load one of the SDFat example sketches and test those; that way you can maybe eliminate your code as the culprit.

7

Yes. All cards fail in the new system but work in the old system.

Yes. I could. However, I'm unable to isolate my module to run those sketches.

However, I've managed to find the problem. Sometimes, the problem exists where you least expect. After re-soldering all the connections, rechecking for continuity and scoping the signals, I was totally thrown off to realize that SD card was getting the correct signals but still unable to read it. I tried to add a beefier 3.3V supply but no luck. I had tried to even load the exact same sketch that works on older system but it will not work.

Finally, I loaded the exact compiled hex code that is present on the older system and it worked! So, it had to be my code. But all I added was couple of debug statements to see why it wasn't working. After much investigation, it turned out to be a mix of two problems.

  1. When things stopped working in the beginning, it seems that for some reason Arduino 1.6.5 that I have wasn't building properly. It had to be quit and restarted for the build to produce the correct output.

  2. To debug that, I had added a debug statement like:

MinimumSerial ms;
...
ms.print("ABC"); //this is where the problem is
configFile.open("config.txt", O_READ);

As strange as it may seem, it turns out that trying to open a file after printing a STRING with MinimumSerial doesn't work. Note that if I print a single character at a time, it all works but a double quoted string is an issue. I've verified it over and over.

I would be delighted to know why that is happening.

Anyways, thanks sterretje for encouraging me.

8

If adding (or removing) Serial prints / writes makes your application misbehave, it's often an indication of a memory issue.

  1. You mention String (capital S); incorrect use of String objects can cause this type of problem. I haven't seen your full code, but e.g. passing a String object as a parameter to a function places a copy of the String object on the stack. It will be better to use a reference to the String object.
  2. Check boundaries of arrays; any writing outside the the array can cause this type of problems.
9

That is possible. I'm left with only 190 bytes for local variables after compilation.

No. Not the String object but a double quoted string. See below:

ms.print("ABC"); //this is where the problem is

Can printing "ABC" cause '\0' to be printed at the end and cause issue?

10

Possibly saving a few bytes of RAM when using ms.print(F("ABC")).

No, the terminating nul character is not printed. I was referring to any array in your code, not (necessary) the array of characters that you show here.

That's not a lot. Is all your fixed text in PROGMEM?

You can check the actual usage by moving local variables to global space and check how memory usage develops. It's probably a lot of work and you might have to rename variables )if variable names are the same in multiple functions.

11

OK. That part is fixed. It saved me 8 more bytes which is probably not bad (about 4% ?).

That is something I had done much earlier but I can look again.

Now, onto more interesting stuff. Just when I thought it was all working, it seems that I tend to receive serial data in my ESP as chunks of 4 bytes! So, if I was sending "ABCDE" instead of earlier "ABC", on using the SoftwareSerial.readBytes API of my ESP, I get the data in two read calls as "ABCD" and "E".

12

That is to be expected. It could also be 2 bytes followed by 3 bytes or 1 byte plus 2 bytes plus 2 bytes. Never expect a serial message to arrive in one chunk.

13

Thank you once again. I modified my code to read byte by byte with a delay in between. It turned out that in the process I uncovered a bug in my code that was reading the bytes. I've fixed it and things look working again.

Thanks again. I'll post more if I run across any issue again.

14

There should not be a need for delay; have a look how things are done in Robin's Serial Input Basics - updated ; it can give you ideas.

15

Great thread! Thank you for pointing me to that. Definitely a lot to learn from it.

In my case, I'm reading serial data in both setup() as well as loop(). Reading within the loop(), in fact, I'm doing exactly what the thread says. setup() is where I've added some new code and I had to use delay() to make it work. However, I've reverted to readBytes() after I fixed the bug that was trying to read an incorrect number of bytes.

16

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.