Integrating FATFS into SYSBIOS

Andrew,

Can you give more info on the hang? Also please attach the *.cfg file.

Moving to a SYSBIOS environment should be direct most of the time. But you have to make sure all the components are included. You can refer the examples included in the ISDK like enetLwip or UartEcho which are derived from starterware examples.

Regards,
Vinesh

Andrew,

I ran into a similar problem with our project and found that the issue was the optimization settings for the compiler. The SD card example does not appear to work with any level of optimization enabled. I think this may be due to the optimization removing a loop in the driver that waits for an ISR to update a variable. There may also be some conflicts with SYSBIOS. I encountered issues even with optimization turned off.

What I am doing is compiling the file system code in a separate project that does not use SYSBIOS and has optimization turned off. Then I am copying the .obj files into the main SYSBIOS project and referencing them in the linker settings.

-Bruce

Vinesh,

I put all of my source and header files into a separate folder in the project and added the include paths.  I included the header file where my datalogging functions are to the main source file where the tasks are.  If I try to make a FATFS call like f_open in one of the tasks, then it will crash during Debug either at Task_Params_init() or Task_create();.

Here's my .cfg file:

3113.app.cfg

On a slightly different note, I discovered that the BIOS packages come with a folder labeled "fatfs" with a bunch of files in them already.  I wasn't able to import them, maybe because they aren't projects, but they are newer versions of FATFS than the one I use.  Has anyone tried using those files instead of the ones from the starterware (v0.08 vs v0.04)?  If those are confirmed to work in a SYSBIOS environment, then maybe I'll just try implementing my code with that instead.

Andrew,

Can you try the suggestion provided by Bruce? Optimizations can cause issues in executing the application.

Also try increasing the heapsize in *.cfg file.

Regards,
Vinesh

Interestingly for me, if I have any optimization other than OFF or empty, then my program won't hang. 
I tried doubling my heap size and the same problem occurs.

What I was able to find out though was that I can't open a file because the auto_mount function keeps returning an FR_NO_FILESYSTEM when it checks for a FAT partition.  In the 2nd check_fs function, it's supposed to place a FAT32 tag on fs->win[82] some time during the disk_read, but it doesn't do this in my sysbios project.  The MMCSDReadCmdSend function returns OK, but that buffer just doesn't get set so when it checks for that tag later, it returns an error.  Any suggestions?

Is anyone from TI still following this?  I read on the Wiki that SysBios only supports FATFS for a RAM disk.  Is this due to hardware limitations or has TI just not been able to work on MMCSD support yet?  The page was last updated in 2012 so I'm not sure if progress has been made.

I tried porting over just about everything from the starterware "boot" project, but I still get the same problem.  I'm pretty sure the issue is due to the interface not correctly sending/receiving the commands to/from the uSD card.  There's no SPI bus initialization or anything for the MMCSD portion, but everything works fine in a nonSysBios environment.  I also looked at the AM335X TRM, but it doesn't say how to set up this interface.

Any suggestions would be appreciated.

I've been able to get the SD card interface to work under SYSBIOS with some modifications. First, use the high-speed methods defined in flasher_hsmmcsd.c under the "SD_card_based_flasher" example included with the Industrial Communications SDK. I had to update the ctrlInfo structure to point to the methods defined in this file instead of the ones they are using in the original example. I also updated the file mmcsd_proto.c in the mmcsdlib Starterware to use the method HSMMCSDCmdSend instead of MMCSDCmdSend. This seems to work around the issues we are both seeing with exchanging commands with the uSD card.

Once those changes were made, I still could not get FatFS to run reliably. I tried a few different versions of FatFS but all of them had different problems. Switching to a commercial FAT file system resolved these issues. I had to write a simple driver to connect the methods defined in mmcsd_proto.c to the hooks for the commercial FAT file system. The SD card interface seems to be working well now with reasonable read and write speeds. If you have multiple SYSBIOS tasks accessing the card, I would recommend controlling access with a semaphore so that only one task is accessing the filesystem at a time. I have tied the SD card file system to a web server and the system will sometimes hang if multiple processes are trying to access the SD card concurrently.

Thank you for the suggestions Bruce.

The bl_hsmmcsd.c file from the boot project is almost the same as the flasher_hsmmcsd.c file.  In the ControllerSetup function, it already calls the HSMMC functions for the ctrlInfo; unless you were talking about something else?  I also tried changing the MMCSDCmdSend calls to HSMMCSDCmdSend in mmcsd_proto.c, but I still get the same problem.

A little more info on my issue:

For some reason after I do my f_mount and call fat_devices[0].dev = &sdCard;, my FRESULT goes rom FR_OK to a 0x38.  I also found that during my f_open, after the disk_initialization call, it messes up the pointers to some of the FATFS variables. 

It seems that you ultimately had to abandon the starterware implementation of FATFS.  Can you tell me where you got your commercial FAT file system?  I may have to go the same route if I can't resolve this.

Andrew,

Those errors are similar to what I was encountering with the FatFS implementation. Someone could probably figure out the issue if they dug down into the FAT specification and patched FatFS to resolve the conflict, but it seems like it might be a big task. I spent a little bit of time trying to fix the issue, but didn't make much progress.

I've been testing the FAT SL library found here: http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_FAT_SL/Download_FreeRTOS_Plus_FAT_SL.shtml . It is open-source for FreeRTOS-based microcontrollers, but needs a license for this AM335x processor. The company that makes this filesystem also has some higher-end versions available that handle multi-block read/write, re-entrancy and file system integrity that I am considering as well. I am still testing to see how well the FAT SL version works using just access control semaphores.

This library seems to be much better organized than FatFS. If you look at the porting guide and source code, you'll see there is an interface for a struct called F_DRIVER. The only two functions that really need to be implemented are F_READSECTOR and F_WRITESECTOR. These can be mapped almost directly to the MMCSD functions in the Starterware examples.

For F_READSECTOR use:

return (MMCSDReadCmdSend(&ctrlInfo, data, sector, 1) != 1);

For F_WRITESECTOR use:

return (MMCSDWriteCmdSend(&ctrlInfo, data, sector, 1) != 1);

I'll definitely look into this.  Thanks a lot Bruce!