TM4C1294NCPDT: why fatfs is creating unknown/weird file in the sd card while copying and renaming the files ??

Hello Dev,

Thank you for the additional details, the problem itself is clearer now but unfortunately we don't have a lot of knowledge with FATFS or SD Card formatting, so I am not sure how helpful I'll be able to be.

One thing I feel reasonably confident about is that an older file system on the Camera should not impact you using the latest on the MCU. The claim is that they are backward compatible with older versions: http://elm-chan.org/docs/fat_e.html

Now then, as far as how to debug the issue itself, one way could be to come up with some form of stress test. You mention the issue occurs rarely, so I would look into how many images are processed between occurences, and then see if you can speed up that process to the point you can actually observe and debug (may require using hardware other than the camera?).

Also it looks like they have full release notes for the updates form R0.09b to R0.13a: http://elm-chan.org/fsw/ff/updates.txt - You may want to review these and see if any functions are used by you and could be impacted by the updates. Perhaps the issue is occurring due a missed update to an API.

Another debug idea would be to leverage UART if possible to add debug messages within the software. This only would work if the issue can occur while the device is plugged into the PC, but if so, you could print out UART debug logs for each step of the process and then see if you can identify what steps were missed/failed when the issue occurred. If you suspect you'll get a large amount of UART data from them, I'd recommend appending a timestamp as well then, so you can compare the UART output logs to the creation of files on your SD card.

I hope one of these ideas has some use to you, sorry that we don't have further expertise to offer on the subject.

Hi Ralph,

How nice to receive your kind comments (especially that "LIKE")  - thank you - appreciated.

As crack millennial staff (often) notes - "Enough smoke has been released in our facility!"      It appears (almost) reasonable - that we've "Learned something."     (maybe)

We outsiders can (rarely) compete w/your group's, "Smarts & Inside Knowledge."     Yet - more often than not - an "overall system view" - advised by the desire to, "Avoid further smoke/fire" - may work to "Poster Advantage."

Might it be noted that, "Varying Perspective" - does at times - offer real advantages... Thanks again...     (and thank you for those "Suggested Answer Hi-Lights - never would I, "Self-Award!")

moul_26feb.txthi,

Thanks for the suggestion.

I have gone through all updates documents and update readme. According to it all changes I made but again I will look into it.

Yes, I am using Uart to debug the issue and I am saving debug log. In that, there are no such failure conditions, Just some hang issues after 6-7 days.For that, I will enable watchdog timer.

Regards

Dev

hi cb1_mobile

*Sd corruption is not static, either both sd are corrupted or any one of them.Both sd cards are of same type (class10 8Gb sd cards).

*When MCU is free then, MCU go into hibernation.This will cut the power from sd cards connector also.

*But mux switching the sd cards according to camera power pin, if a camera gets off we will switch sd cards. Insertion/removal of sd cards performed after removing power sources.

*No there is no high-frequency switching sources.

*But yes there is CDMA module but currently it not in use.

*This is how I am copying and renaming.

void SAVE_IMAGE(void)
{
 uint8_t Folder[200] ={"/SENT/"};						//	Save file 
 in the sent folder 
	//iFResult = f_mkdir ("/SENT"); 				//	Create a new directory 
	sprintf((char *)Folder,"/SENT/%s",dest_name);
	if(EPROM_cnfgSettings.img_rsz==0x33)
	{
	DEBUG_PRINT_TIME();
	DEBUG_PRINT((uint8_t *)"\t\t");
	DEBUG_PRINT((uint8_t *)"Renaming ");
	DEBUG_PRINT((uint8_t *)FIL_NAME);
	DEBUG_PRINT((uint8_t *)" to ");
	DEBUG_PRINT((uint8_t *)Folder);
	DEBUG_PRINT((uint8_t *)"\r\n");
	iFResult = f_rename((char *)FIL_NAME,(char *)Folder);
	
   if(iFResult!=FR_OK){
	DEBUG_PRINT_TIME();
	DEBUG_PRINT((uint8_t *)"\t\t");
	DEBUG_PRINT((uint8_t *)"Failed!!So Renaming ");
	DEBUG_PRINT((uint8_t *)FIL_NAME);
	DEBUG_PRINT((uint8_t *)" to ");
	DEBUG_PRINT((uint8_t *)dest_folder);
	DEBUG_PRINT((uint8_t *)"\r\n");
	iFResult = f_rename((char *)FIL_NAME,(char *)dest_folder);						
	if(iFResult!=FR_OK){
	DEBUG_PRINT_TIME();
	DEBUG_PRINT((uint8_t *)"\t\t");
	DEBUG_PRINT((uint8_t *)"Failed!!So deleting ");
	DEBUG_PRINT((uint8_t *)FIL_NAME);
	DEBUG_PRINT((uint8_t *)"\r\n");
	iFResult = f_unlink ((char *)(FIL_NAME));	
	}
   }
  }
else  
	{
	iFResult = f_unlink ((char *)(FIL_NAME));	
	DEBUG_PRINT_TIME();
       DEBUG_PRINT((uint8_t *)"\t\t");
	DEBUG_PRINT((uint8_t *)"Renaming ");
	DEBUG_PRINT((uint8_t *)original);
	DEBUG_PRINT((uint8_t *)" to ");
	DEBUG_PRINT((uint8_t *)Folder);
	DEBUG_PRINT((uint8_t *)"\r\n");
	iFResult = f_rename((char *)original,(char *)Folder);
			
	if(iFResult!=FR_OK){
	DEBUG_PRINT_TIME();
	DEBUG_PRINT((uint8_t *)"\t\t");
	DEBUG_PRINT((uint8_t *)"Failed!!So Renaming ");
	DEBUG_PRINT((uint8_t *)original);
	DEBUG_PRINT((uint8_t *)" to ");
	DEBUG_PRINT((uint8_t *)dest_folder);
	DEBUG_PRINT((uint8_t *)"\r\n");
	iFResult = f_rename((char *)original,(char *)dest_folder);
	if(iFResult!=FR_OK){
	DEBUG_PRINT_TIME();
	DEBUG_PRINT((uint8_t *)"\t\t");
	DEBUG_PRINT((uint8_t *)"Failed!!So deleting ");
	DEBUG_PRINT((uint8_t *)original);
	DEBUG_PRINT((uint8_t *)"\r\n");
	f_unlink ((char *)(original));	
  }
}			
}
ClearBuffer((char*)temp_FIL_NAME);	
sprintf((char *)temp_FIL_NAME,"%s",FIL_NAME);
SDCARD_MEMORY_CALCULATION((char*)"/SENT");  	// 	Check if the memory is full, if yes then images need to overwrite or delete oldest after 20%
		if (Response[1]<= 0x14)
		{
		MEMORYFULL();																								//	If memory is full then process according to settings
		ClearBuffer((char*)FIL_NAME);	
		sprintf((char *)FIL_NAME,"%s",temp_FIL_NAME);
		}
}

Thank you - the "new detail" you've provided always assists our, "Drive toward the solution."

This is the first time we've noted that "Hibernation" is in play.      There are (many) variables w/in your operation - some are "candidates for SD card disturbance" - it is difficult to know, "Where to begin" under such circumstance.     I suggest that you (temporarily) REMOVE "Hibernation" from the mix - and run the system EXACTLY as BEFORE - seeing if  "hibernation" proves "causal-nexus."     (It is a prime suspect - to my mind!)

You have "self-diagnosed" the issue as being triggered by,  "Copying and Renaming the files" - while those files are resident upon two (attached) SD cards.     May I ask, "How you've come to such conclusion?"    After a reasonable "scan" of this building thread - I cannot find your explanation nor justification - for such conclusion.     And I think many would agree - (as the irony in your thread's Subject Line notes) - such simple, (Copy & Rename File) - causing SD card corruption - is a (much) Unexpected Occurrence!

I quote now from your initial posting, "Now my issues are that after 2-3 days running the filesystem starts creating some weird files and also sometimes it is corrupting sd card sector/cluster."

Does it not prove useful for you to (somewhat) "detail" - what occurs during this, "2-3 day interval" - prior to your, "Detection of (either) weird or corruption?      There's a clause w/in your quote which yields  uncertainty, "after 2-3 days running the filesystem" as written - this suggests that you've been, "Running your system - likely updating the SD cards."      Yet - if  punctuation is added, "after 2-3 days, - (then) running the filesystem!"     This 2nd interpretation of your writing suggests that your system "sat idle for 2-3 days" - and your issue only arose (or was noted) - after that 2-3 days passage."        Might you clarify - we believe this to be important.

It remains unclear,  "How and when" you first note the issue?     I have asked that you create (only),  "known good files" - and store these on each of the two SD Cards - and then, "Leave the system to itself - for a similar - 2-3 day period."    And then - test for "weird/corruption!"      As "No files have been "Copied nor Renamed" - should corruption (now) occur - your diagnosis may have been proven to be, "incomplete."    (it still may arise - but OTHER issues have just been PROVEN to exist!)

The final suggestions - w/in my prior "Diagnostic Listing" created in your behalf - appear (not) to have been adopted.     Yet those are the ones (restated here) which I believe to "go far" to, "Confirming an "Unlikely Diagnosis."

As neither firm nor I employ your MCU - it would be greatly helpful if  Vendor Agents would be so good as to review your code - and judge its effectiveness.    I would note, "Adding Delays" between critical aspects of your "Copy & Rename" code - may prove helpful...    (even "solving!")

One last point - you mentioned adding a "camera & SD Card" - are you (absolutely) certain that your board's power supply - proves adequate - especially when, "So many external devices are Drawing Current?"    (firm/I have seen such issues - caused by inadequate power (under special circumstances) - often enough to warn you to (really) "Test & Verify."     (hope/guess proves NOT acceptable...)

it is suggested that you follow the later suggestions w/in the earlier Diagnostic list.     Variables need to be minimized (discarded, really) - and those suggestions  move nicely in that direction...

IF - after truly, "Following and clearly reporting your findings" - and desired results are not achieved -  my firm has developed,  "Unique & highly advanced methods" to,  "Speed & Enhance the ARRIVAL of such Faults/Issues" - which surely  Aids/Propels diagnosis.     (I'm disallowed from presenting those here - you may contact us privately (via PM) this forum - if such is sought...)

Your present situation is,  "HIGHLY ANTI-KISS" - and the, "EXCESSIVE NUMBER OF "NOOKS/CRANNIES" (especially the earlier identified "Hibernate") can be expected to (continue) to Over-Challenge!