FatFS issues on AM3359 board

Using which parameters do you f_open() your file? You should not use FA_CREATE_NEW or FA_CREATE_ALWAYS in order to append to an existing file.

I've tried FA_OPEN_EXISTING and FA_OPEN_ALWAYS along with other combinations of FA_WRITE and FA_READ and it doesn't affect the end result.

Hm, sounds good so far...may be they can help you at http://elm-chan.org/fsw/ff/bd/ but I'm not sure if they offer some support for the really old version of FatFS that comes with Starterware...

Hi Andrew,

I assume you are already using an f_close () or f_sync function to update the File allocation tables with the new file size after making the f_write() call.With reference to ff.c f_sync function calls sync()  which in turn calls move_window () to update the directory entries. Could you please check whether this flow is followed in your call stack?

Another point is that current version of the FATFS does not support LFN -long file name format . Hence all file names should be of 8.3 format (" Filename.txt").

As with regard to 4GB support, could you check  the auto_mount () for the value of the FAT subtype .

line 707  fmt = FS_FAT12; /* Determine the FAT sub type */
              if (maxclust > 0xFF7) fmt = FS_FAT16;
              if (maxclust > 0xFFF7) fmt = FS_FAT32;

The drive should be mounted as a FAT32 subtype for all 4GB to be used.

Hi Vineeth, yes my program follows that call stack for f_close.  move_window also ends up calling disk_write --> MMCSDWriteCmdSend-->which then sends a CMD24 which is the write SPI command.

I'm pretty sure I'm following the SFN format.  Here's what my code looks like:

fresult = f_open(&g_sFileObject, "test1.txt", FA_WRITE|FA_OPEN_EXISTING);

fresult = f_lseek(&g_sFileObject,f_size(&g_sFileObject));

fresult = f_write(&g_sFileObject, writebuffer, sizeof(writebuffer), &usBytesWritten);

fresult = f_close(&g_sFileObject);

I did get appending to work at one point when I manually moved the pointer past the end of the file by using an f_lseek after the f_write.  But after cleaning up my code a bit, it stopped working for some reason.

Also, right now I seem to be reading and writing a bunch of garbage text to my text file.  Not sure if that's related or a separate issue. 

*********** Update ************

I was able to get it to append data.  Was running into NULL char errors and corrupt files.  Had to add a -1 to the sizeof(writebuffer).

So now I can write to the file, read it back, and it displays correctly on the terminal, but when I take out the card and open it on my computer, none of the appended data shows up.  And if I put it back in the board, then there's only the original data again.  I've tried using f_sync and f_close.  Anyone have any idea why this would happen?

Also, I know the TI instructions say to format the uSD card with the HP format utility program, but I was never able to get it to detect my card, so I just format my cards with Windows.  How critical is that step?  I'm asking because it seems like my readback works on FAT but not FAT32.

Hi Andrew,

I tried to append data to an existing file on a pendrive. The usb examples in starterware use the same file system and hence if it works for a pendrive it would work for an SD interface. I used release 02.00.01.01 for this test.

1. Formatted a pendrive with RUFUS (http://rufus.akeo.ie/) as a FAT drive and then appended info to an existing file. The file append succeeded and the new data could be read in windows.

2. Formatted a pendrive with USB disk storage format tool 5.0  as a FAT32 drive and then appended info to an existing file. The file append succeded. The.The drive also got detected as a 4 GB FAT32 drive. 

Formatting using the HP format utility/ any similar utility:

I think this is critical as I have noticed that a quick format with windows messes up the FS. I have also noticed that older files (entries removed from the FAT) are detected when you do a quick format. Could you please try with any of the above mentioned utilities to do a full format of your SD card?

Hopefully with the latest version of the FATFS , these problems would go

My code snippet:

fresult = f_open(&g_sFileObject, "file1.txt", FA_WRITE|FA_OPEN_EXISTING);
fresult = f_lseek(&g_sFileObject, g_sFileObject.fsize);
fresult = f_write(&g_sFileObject, writebuffer, sizeof(writebuffer), &usBytesWritten);
fresult = f_close(&g_sFileObject);

Hi Vineeth, thank you for the suggestions.  I tried a couple of new card formatters, but they seem to produce the same results.  I may just stick with FAT as that seems to be more stable for me.

I did come across a new issue.  When the 512 byte buffer from the &g_sFileObject is full, and I write a new string of data to it,  then perform an f_lseek, it wipes out(fills with empty spaces) a chunk or all of the new data I just wrote into that buffer.  I can still continue to append data, but every 512bytes, some data will be lost.  It seems like some sort of sector issue.  Do you think you can check to see if this is the case for you as well?  For some reason I have to do another f_lseek after an f_write in order for my data to be appended.

I'm using the version of starterware that came with the SYSBIOS SDK package 1.1.0.3 which I believe is the latest version.  Thank you.

Hi Andrew, 

I have not tested that yet. While going through the File system website , I have found that a lot of bugs have been fixed in the later versions of this FS library. It is available at

http://elm-chan.org/fsw/ff/00index_e.html

Rather than fixing bugs in the old code base , it seems to be prudent to move into the new one. Could you please give it a try.

I've tried using the newest version of FATFS from that website.  I ran into errors just mounting and opening files so I went back to v0.04b since I assume that it actually works with the other starterware files.  I didn't see anything in those update notes that seemed to be related to my issue.

I did discover that the SYSBIOS package I downloaded has a fatfs folder with v0.08 on it.  It doesn't seem like there is an existing project using those files though so I'm not sure how reliable it is.

Funny...how do you force the "ptr" to be cache-aligned?

In the starterware hs_mmcsd example, file hs_mmcsd_rw.c, in the "variable definitions" section near the top of the file:

#ifdef __IAR_SYSTEMS_ICC__
#pragma data_alignment=SOC_CACHELINE_SIZE
unsigned char data[HSMMCSD_DATA_SIZE];

#elif defined(__TMS470__)
#pragma DATA_ALIGN(data, SOC_CACHELINE_SIZE);
unsigned char data[HSMMCSD_DATA_SIZE];

#elif defined(gcc)
unsigned char data[HSMMCSD_DATA_SIZE]
                    __attribute__ ((aligned (SOC_CACHELINE_SIZE)))= {0};

#else
#error "Unsupported Compiler. \r\n"

#endif

Use something similar to force a global variable to have a particular alignment. In the case of the FIL struct, the buf member (which appears to be the only member needing cache alignment) has a different alignment that the base. My struct starts as follows:

typedef struct

{

DIR Directory;

FIL File;

...

} mystruct;

When mystruct is aligned, File->buf is also aligned.