cancel
Showing results for 
Search instead for 
Did you mean: 

Getting FR_INT_ERR when using f_seek in ff.c

JayDev
Senior II

Hello!

I was opening a file and trying to read from a specific index of a file on my SD card. I used the following code:

FIL fHandle_filename_file;
char SDFileName[256] = "filename_1234.BIN";
 
res = f_open(&fHandle_filename_file, SDFileName, FA_OPEN_EXISTING | FA_READ);
res = f_lseek(&fHandle_filename_file, 1024);

I receive an FR_OK when I open the file, so it seems to be finding the file and is able to open it. When I try and move to index 1024, I receive the error FR_INT_ERR .

I stepped through the f_seek function and below is the code:

FRESULT f_lseek (
	FIL* fp,		/* Pointer to the file object */
	FSIZE_t ofs		/* File pointer from top of file */
)
{
	FRESULT res;
	FATFS *fs;
	DWORD clst, bcs, nsect;
	FSIZE_t ifptr;
#if _USE_FASTSEEK
	DWORD cl, pcl, ncl, tcl, dsc, tlen, ulen, *tbl;
#endif
 
	res = validate(&fp->obj, &fs);		/* Check validity of the file object */
	if (res == FR_OK) res = (FRESULT)fp->err;
#if _FS_EXFAT && !_FS_READONLY
	if (res == FR_OK && fs->fs_type == FS_EXFAT) {
		res = fill_last_frag(&fp->obj, fp->clust, 0xFFFFFFFF);	/* Fill last fragment on the FAT if needed */
	}
#endif
	if (res != FR_OK) LEAVE_FF(fs, res);

When i use the offset value of 0, it works fine. When I use anything else, it seems to get the FR_INT_ERR code from the "fill_last_frag" function (I am using an exfat formatting SD card).

The file itself is 800 Kb,so I'm not exceeding the file size. Not sure if I have a setting incorrect on the SD card, if I'm using the function incorrectly, etc. I thought someone in this forum might have seen this issue before but haven't ran into any posts.

If someone can help me understand what might be going on or how to resolve this error, I'd appreciate it. Thanks for the help!

2 REPLIES 2

>>If someone can help me understand what might be going on or how to resolve this error, I'd appreciate it.

What version of FatFs are you using? R0.12c ??

Get a more current version so as not to waste a lot of time fighting large volume bugs which were remedied years ago.

I'd tested some of the latter versions of R0.13 on media out to 200 and 400GB

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

You are correct, I'm using R0.12c (which is what STM32CubeIDE seems to use).

Hmm, you might be onto something there!

I was looking at the changelogs and came across this:

R0.13 (May 21, 2017)

 Changed heading character of configuration keywords "_" to "FF_".

 Removed ASCII-only configuration, FF_CODE_PAGE = 1. Use FF_CODE_PAGE = 437 instead.

 Added f_setcp(), run-time code page configuration. (FF_CODE_PAGE = 0)

 Improved cluster allocation time on stretch a deep buried cluster chain.

 Improved processing time of f_mkdir() with large cluster size by using FF_USE_LFN = 3.

 Improved NoFatChain flag of the fragmented file to be set after it is truncated and got contiguous.

 Fixed archive attribute is left not set when a file on the exFAT volume is renamed. (appeared at R0.12)

 Fixed exFAT FAT entry can be collapsed when write or lseek operation to the existing file is done. (appeared at R0.12c)

 Fixed creating a file can fail when a new cluster allocation to the exFAT directory occures. (appeared at R0.12c)

Sounds like that might be the issue I'm running into. Unfortunately for me, my project is using the *.ioc framework and dragging and dropping the files in was not as easy as I'd like (a lot of the variables were named from CODE_PAGE to FF_CODE_PAGE and that kind of thing so anything explicitly dependent on the version I have needs to be found and fixed. Not a deal breaker but not an easier solution either, unfortunately.

Regardless, thanks for all your help! At least I was able to find an explanation for the issue I'm running into!