Data Logging through SD Card

Might you want to share your MCU, IDE and clarify your statement, "seems to work fine w/out ADC function?"

When the ADC code is completely bypassed (if that is the case) are you - then and only then - able to write data to the SD card multiple times - and then recover that data to confirm its correctness?

If you can perform multiple/correct SD card transactions would it not be useful to gradually "re: set-up/config" your ADC - and continue adding ADC code - until the SD card becomes impacted?  That latest code addition - causing the SD disruption - would then bear your analysis/investigation.

Classically - when "peripherals collide/encroach" - there may exist a resource conflict (i.e. same pin(s) is "grabbed" by multiple peripherals) or one peripheral may enjoy a far higher interrupt priority - likely "starving" the other. 

Check too that the code regularly "visits" each peripheral calling function - when multiple peripherals are in play.  By incrementing a simple SW counter - placed uniquely w/in each peripheral service routine - you gain needed insight that your code has - at minimum - "reached its destination" - and that some way/how that code has failed to execute (or has not executed correctly or to completion.)

Alan Tan said:

I'm only able to write the data into the SD card once and the very next time, the fresult of f-open shows "FR_NOT_READY". Why is that so?

 Indeed CB1 analysis is correct and the best one, much better of what we can do with incomplete details you furnished to us...  This issue remember me what I experienced running the SD card example and adding some more part where I was sure no stack overflow in place measuring maxstack on interrupt but IDE foolished me, stack was set at much more low as expected...

 So from that experience stack overflow return that error, increase stack, depending on (unspecified) IDE you are using we can try some way of more help.

Hi,

MCU: TM4C123GH6PM (Tiva C Series TM4C123G Launchpad)

IDE: CCS v6

Yes I do mean that if there isn't any ADC involved, I'm able to write continuously into SD card without any error. I have just "re: set-up/config" my ADC and apparently the fault kinda lies in the ADC portion. When the sample sequencer is set to 3 (meaning only sample one channel), the SD card is able to do multiple transaction. But when I change the sample sequencer of ADC0 to 0 (sample 8 channels at max), the SD card will show FR_NOT_READY after one transaction ( One transaction = f_open -> f_write -> f_close).

Alan Tan said:

...change sample sequencer to 0 (sample 8 channels at max), the SD card will show FR_NOT_READY after one transaction

Might this signal that you're not allowing the ADC to properly/fully complete its conversion sequence?  Usually the ADC code examples show the inclusion of a while loop - which "spins" until the ADC interrupts - signaling completion.

Under code>peripherals>examples>ADC this mechanism is well illustrated - surely this merits your review/consideration...

Alan Tan said:

else if (SW3 == PRESSED){

f_close(&g_sFileObject);

}

 This is a BAD practice due processor are more faster closing file than you pressing switch, a pressed unpressed mechanism has to be in place to avoid multiple entering this part of code...

 Also a check for file is open is good before to try closing. IN regular OS this cause a fault, here can do impredictable issue.

Alan Tan said:

if (SW1 == PRESSED){

// Open the file & change filename if exists
do{
sprintf(g_cFilePath,"/File-%d.csv",fileNum);
g_cFilePath[0]=0x2F; //to ensure the blackslash is written into the filename string
fresult = f_open(&g_sFileObject, g_cFilePath, FA_CREATE_NEW|FA_WRITE); //always create new file if not exists
fileNum++;
}while(fresult == FR_EXIST);

// start reading of ADC inputs by the use of ADC interrupt

}

 Like closure this is twice worst, not only multiple open execution but also loop till file created and no closure before reopen, also this on regular OSes can cause e fault raise.

Alan Tan said:

else if (SW2 == PRESSED){

// Stop ADC interrupt

for(i = 0 ; i < LENGTH ; i++)
{
memset(ccNum,NULL,sizeof(ccNum));
sprintf(ccNum,"%u,%u\n",ui16CH1Value[i],ui16CH2Value[i]);
fresult = f_write(&g_sFileObject, ccNum, sizeof(ccNum), &bw);
}

 Also bad but less dangerous than preceding, at least this can fill up your storage device.

@Roberto,

You've blown me away here - with this.  C'est tres bien - merci - bit incomplete post -> incomplete response - till Roberto arrives - resolves...  Good stuff, man.