I am curious if there is an easy way to check if the SD card is busy to make sure I don't try and write/read from the card during the process. I have discovered that the SD card works great when using the Arduino various boards. The exception is when using the 328 micro with 3.3 volts, it will reset my program after various hours of use. My project is for taking data at a slow 1 second interval for a few days at a time. The program seems to reboot ok, but don't like the idea of what appears to be random reboots. Same program works for days if running at 16MHz at 5 volts and any of the 32bit units work just fine so far. I can post my program but in addition to my program, tried most of the example data loggers with the same result. I am just reading in data from a serial port at 100k baud and saving to SD card at 1 second interval. It sure appears to be that it is a timing problem that would be solved if I could poll the SD card to make sure it is not busy. I don't care if I miss a few seconds of data during the course of the log. I also tried the SD card formator and it definitely helped a lot, and can now get about 15 hours of data before a reboot. I have tried many SD cards and only use the cards with the fastest bench time using the bench program for SD cards that is available as an example in the SDfat library. The card that has the best performance for my application is the SanDisk Ultra Plus 16G cards. I am sure I could add a command to the SDfat driver but short of spending time on this, thought I would check if I missed a simple way of checking from all of the examples that are out there regarding the SDcard. In the future, I will avoid using the 328 running at 8MHz and 3.3 volts, but for now I have a board that is going out to a customer and stuck with it until the next board rev.
I realize that code is usually posted but in this case I have several hundred hours of testing on various platforms and only have the problem with the 328 running at 8MHz and 3.3 volts. I am fairly certain it is a timing problem due to additional time the SD card sometimes requires and the SD card is not finished within the 1 second before more data is available at the serial port.
Same program works for days if running at 16MHz at 5 volts and any of the 32bit units work just fine so far.
Why do you, then, suspect that the problem with the 3.3V model is related to the SD card/library?
If the card/library IS busy, it is not going to be able to respond to "Are you busy" kinds of requests, until it is done, at which time it will return false. If it isn't busy, the answer will always be false, immediately. I can't see how that would possibly help you.
What would you do while the card was busy, if there were some way to determine that?
Thanks for the replies. I also did tests doing nothing with the serial port and just repeating the same string to the SD card at 1 second intervals. Same problem. There is nothing left in the program at that point other than the SC card routine. I also tried flushing every time, every 512 bytes, and stuff in between and it did not make a difference. I think a busy sort of command would help. To answer your comment, I am thinking if I get no response, I wait until I do get a false for busy. No response is assumed to be busy. The program would pause until I get a not busy. Don't know about the SD card but some IC have a bit you can check even when the chip is busy just for this purpose. I know the answer for me is not to use this combination in the future, but curious if a solution exists for the short term. Thanks!
Checking if the card is busy isn't even relevant unless you try to access it in the main program and in an interrupt at the same time. That can mess up the library's variables (only in runtime) and potentially corrupt critical filesystem's data (or just the particular file data if you're lucky).
Otherwise it doesn't matter, because anyways the library won't let you execute anything else until it's done with reading, writing, opening or closing.
About your other problem... I would check the supplied voltage if I were you.
Sudden resets are usually caused by undervoltage spikes (is the power supply being overloaded by capacitor charges or motor startups?); since most AT microcontrollers have a feature called "Brown-out detector", which basically pulls (internally) the reset line low (the equivalent of pressing the button) as soon as it detects that the supplied voltage is too low to operate stably.
3.3v is closer to the BoD's trigger threshold than 5v, so this is why I think it's most likely the cause.
Thanks for your reply! You are correct and the problem appears to be an occasional spike in the 3.3 volt supply. Not sure what is causing it yet, but a large value capacitor appears to have eliminated the problem. I did set up the fuses for the BoD to be appropriate for the 3.3 volt supply when I originally loaded the bootloader, but apparently the spike drops low enough to be a problem. When I was testing the firmware with the 5volt setup, it was not in the complete system, hence did not have the supply problem. It all makes sense now. Thanks again for your help!