SDFat crashes Arduino???

adwsystems:
Only difference is it cost 8 bytes to do it this way.

I provided a default label for invalid cases - it costs the same without that. The potentially uninitialised buffer that you have could cause problems.

adwsystems:
Then I'm sorry to say, you don't realize what it does or why it is there. The purpose can be made evident if you run the function on the arduino and lcd without that one line. I'm sure there are other ways, but this is a simple guaranteed generic and reapplicable way.

I thought it was to align the text, but I could be wrong. Irrespective, it is likely unsafe even if it works.

arduarn:
I provided a default label for invalid cases - it costs the same without that. The potentially uninitialised buffer that you have could cause problems.

I thought it was to align the text, but I could be wrong. Irrespective, it is likely unsafe even if it works.

As you mentioned - personal opinion. I have entertained this side trip out of curiosity. It has had not effect on getting the problem resolved.

I went ahead and uninstalled the Arduino IDE and deleted the libraries directory. Then downloaded the same version of the IDE (I have run into problems in the past when updating and did not want to involve that change in this problem) and allowed the IDE to download the most recent versions of the libraries included (I only use libraries from the library manager since the fmalpartida lcd problem a few years back). So the IDE is all rebuilt with fresh loaded libraries. The program still compiles and runs until it hits the SDFat line for file.open(). It would appear the install is not corrupt but there is a problem with SDFat? Should I try a previous version?

Delta_G:
According to #22 you have something in here that the specifications say is undefined. The thing you have to realize about that statement is that it means that the effect of that code might not make any intuitive sense. That line could cause a reset, it could cause an issue way up in setup, or it could cause little demons to fly out from your nose and those would all be perfectly reasonable things.

When you have something that is documented as undefined then it is useless to try to debug any further until that is fixed. Even if it isn't your problem you don't know that it won't become a problem as soon as you fix the other problem.

I see in #23 where you try to talk about why you did it that way. But that doesn't matter. What you don't understand is that the function might cause who knows what to happen in that condition. You'll have to find another way to do that. sprintf doesn't work that way. It just doesn't. And no amount of bloviating on your part will make it.

To prove that wasn't the problem, just in case, I added a strcpy to move line_text to temp_text and then changed sprintf(line_text, "%-20s", temp_text); nothing changed program still crashes in the same place.

Next please.

Delta_G:
Have just a little respect and courtesy.

I'm trying, but the propensity on this forum when faced with a problem statement like this is to chase squirrels. At least no one has made any replies on programming style or method. Well, there was one but it also included a different way to accomplish something that I had never thought of so I am giving it a mulligan.

Delta_G:
At least we are finding possibilities. You don't have the first clue.

The bummer is the possibilities have been a stretch. The sprintf statement and changing to a MEGA. Using sprintf like that came from a text book 20+ years and have never ran into an issue. I did change it as it didn't cost any RAM as both variables were already defined. I tried changing to a MEGA and ran into the same issue.

I did learn about the lcd.clear function, a plus but not related to the issue. I applied the F-macro to the temporary debug statements, but that also had no effect.

Have I missed any possibilities?

(the 21 versus 25 isn't an issue as the word COMPLETE doesn't get put into the sprintf statement listed)

adwsystems:
It would appear the install is not corrupt but there is a problem with SDFat?

Have you tried making a small, simple program that only exercises the same SDFat functionality as your complete project? Did it work without crashing? If so, you'll have a hard time supporting that claim.

gfvalvo:
Have you tried making a small, simple program that only exercises the same SDFat functionality as your complete project? Did it work without crashing? If so, you'll have a hard time supporting that claim.

If it did work, then what does that say?

If it did not work, what does that say?

Either way it circles back around to this sketch. Either way it needs to work in this sketch.

@Delta_G is correct. Attitude goes a long way towards helping people form an opinion. Especially a bad attitude.

gfvalvo:
Have you tried making a small, simple program that only exercises the same SDFat functionality as your complete project? Did it work without crashing? If so, you'll have a hard time supporting that claim.

If it did work, then what does that say?

If it did not work, what does that say?

Either way it circles back around to this sketch. Either way it needs to work in this sketch.

Delta_G:
The SDFat library has been working in countless other projects that do something very nearly the same as what you are trying to do.
...
I seriously doubt that this is an issue with SDFat unless you can tell me what it is that you are doing with it that is unique.

That is actually what I'm suspicious of. Something in my sketch that is incompatible with SDFat. Timers, interrupts, or the like that I am (unknowingly) "reusing".

Delta_G:
Plus I see several cases of poor programming practice (undefined behavior especially) in your code.
...
And I've seen plenty in your code that I know CAN cause an issue. So I'm going to chase the known stuff first. That's regular debugging.

Such as? You have me curious.

Delta_G:
That's a pretty easy question to answer. What resources are your program using? What resources does SDFat use? You've got the library. Look. Does it define any interrupt handlers? They're easy to spot by the "ISR" at the beginning. Does it have any Timer code in it? Timer code is easy to spot by the pre-processor macros that go along with it to help it work with multiple boards.

What does SD normally use? SPI for sure. Are you messing with that?

I did look. I don't see any overlaps, but I'm only an expert on the sketch I wrote not on the published library someone else wrote and that (I am sure) many others are far more familiar with than I.

I am not messing with any of the published libraries. They are being used as installed by the Arduino IDE. Makes it far easier if someone else wants to test my code. Simply start the IDE and install the libraries from the manager. No links needed (just the exact name and perhaps the version).

Additionally, I have only 1 SPI device, the SD card. It is an older Adafruit Datalogger using the DS1307 RTC.

Delta_G:
It's just that if it doesn't fix this particular issue right away then you go on and ignore it.

Delta_G:
Have you not been following this thread? It's just that if it doesn't fix this particular issue right away then you go on and ignore it. The sprintf thing was a really good catch on someone's part. Instead of contempt, you should be thanking them for saving you before it does suddenly start causing a problem when you add some seemingly unrelated code to some seemingly unrelated section of your program.

Yes. I have ignored nothing. I have tested and responded to each suggestion posed. I have tested and addressed the issue that @arduarn found as well as as the COMPLETE item posted by @sterretje and ALL of the others.

Delta_G:
Have you not been following this thread?

Don't get defensive. I simply said that I was curious about what you found. What did you see beyond what was already mentioned? Or do you need the usual page or two of beatings before I am sufficient chastised in this thread before you are ready to enlighten us.

Delta_G:
You don't need to be an expert on the library. It's not some esoteric thing. It's just code. It either has timer code in it or it doesn't. (It doesn't). You don't need to be able to understand everything about SD cards (even though that is trivially simple) you just need to look at the code and see if it defines any ISR. That's simple. Technically, you don't even need to be able to read to do that. My three year old is just learning her letters and I bet I could have her go through and see if she finds an "I" followed by an "S" followed by an "R" anywhere in there.

You're making this harder than it needs to be.

Please let me know when you are ready to tell me the thing that is obvious to you but I have overlooked (likely by looking too deep rather than at the obvious item on the surface). Until then, please save your effort of typing.

Delta_G:
And I was trying to help you do that.

You are? What is your suggestion of what to check, test, or change? Because I don't see any. All I see is badgering and no new direction in any of your posts.

gfvalvo, sterretje, and arduarn have all given pointed suggestions and items. I am not seeing anything but badgering or generic innuendo on your part.

Delta_G:
I was the first one out of the blocks.

Did the F-macro thing on everything I could. The serial and file prints. Please review the posts.

Delta_G:
Why are you acting like I was wrong on purpose or something? It was a good first guess and by fixing it you ended up with better code. Why are you mad about that? If it were my code it would have been my first step.

Not that it was wrong, just irrelevant. The program broke in exactly the same spot before I added the those print statements. Those print statements were specially added to show proof positive to this group where the program was crashing. I didn't need them. I knew where the program was crashing because I have and can see the hardware (LCD). But knowing (some of) the folks on this forum, something similar to this would be demanded.

Asking as nicely as I can, what else have you seen in regards to

Delta_G:
Plus I see several cases of poor programming practice (undefined behavior especially) in your code.
...
And I've seen plenty in your code that I know CAN cause an issue. So I'm going to chase the known stuff first. That's regular debugging.

that I should try to address?

Delta_G:
How was I supposed to know that from the OP? How from the OP with only that snippet was I supposed to know that those types of statements weren't sprinkled all over your code.

You didn't at the time. I am fine with that, so you were (politely) informed those statements were added only for debugging as reply #5

Delta_G:
Forget this. You're pretty unpleasant to deal with. I'll go help someone who actually wants to fix something.

Bye now.

I want the help. I need the help. But the fact is that you can't help. You don't know the problem or you can't find the problem. You are as stumped as I. You're hoping to get lucky and close and then one of us will randomly stumble across it. You have added seven posts (and I seven replies) and you haven't had one new thought, piece of new information, place to look, or test to perform to identify the problem. (actually in 12 posts there has only been 1 suggestion).

As I said six posts back,

adwsystems:
What is your suggestion of what to check, test, or change?

Please make suggestions and not insults. If you want to go away, then please do. You are helping the situation and it will leave room for someone that can find the problem.

So is there a programmer willing to take on the challenge?

Attached is the updated program with all relevant recommended changes included. The program crashes upon reaching the file.open() instruction in the run_test() function. (see post #1).

The compile stats are:
Sketch uses 21810 bytes (67%) of program storage space. Maximum is 32256 bytes.
Global variables use 1632 bytes (79%) of dynamic memory, leaving 416 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.

All libraries are used directly (unmodified) from the library manager.

I am aware you don't have the hardware. If you feel there is a test to be performed requiring the hardware, just let me know.

SDFAT_Test_post.ino (21 KB)

In run_test()

  // test for end condition
  if (((Run_Status == RUNNING) && (battery_voltage < (voltage_sel * 100))) || (Run_Status == STOP))
  {
    if (Run_Status == STOP)
    {
      Run_Status = STOPPED;
    }
    else
    {
      Run_Status = COMPLETE;
    }
    file.close();
  }

You close a file that you did not open.

sterretje:
In run_test()

  // test for end condition

if (((Run_Status == RUNNING) && (battery_voltage < (voltage_sel * 100))) || (Run_Status == STOP))
  {
    if (Run_Status == STOP)
    {
      Run_Status = STOPPED;
    }
    else
    {
      Run_Status = COMPLETE;
    }
    file.close();
  }



You close a file that you did not open.

Good point. But the code doesn't get that far. I did remove the line in question. No change.

Delta_G:
Go here. Read the part at the top and then go to the bottom of the page and get that code in the very last one.

Build a minimal example sketch with SdFat. Just open a file and write some junk to it and close. Be sure to F() everything so it doesn't affect the measurement. Put that call before and after you open the file and see how much it changes. Report back.

Next, add it to your code and call it just before the crash point where you open the file. Be sure to Serial.flush() after you call this so it blocks and the serial gets out before the crash. Compare those numbers. What do you see?

You are talking about the freeRAM() function?

int freeRam () {

extern int __heap_start, *__brkval;
  int v;
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}




and call it anywhere in your program like that: Serial.println(freeRam());

Interesting function. I will give it a shot and report back. The minimal SDFat sketch will do everything in setup(), one shot, freeRAM before and after file.open.

In the meantime, how does this apply to the sketch not working on a MEGA (see post #15)?

Your code crashes on this line:

if (!file.open(log_filename, O_CREAT | O_WRITE | O_EXCL))

Which happens to be the first location where you try to use the SD card.

You forgot to add sd.begin() in setup().

According to GitHub - greiman/SdFat: Arduino FAT16/FAT32 exFAT Library, this is the prototype:

bool SdFat::begin(uint8_t csPin = SS, SPISettings spiSettings = SPI_FULL_SPEED);