Does any one made SDCARD/MMC works with valueline MCUs

[gssmahadevan 2]

Hi,

Does any one ported FAT file system on the Launchpad series MCUs (all value line MCUs whose max SRAm is 512 bytes)?

 

I know FAT sector needs atleast 512 bytes and all of the valueline MCUs has SRAM lesser-or-equal to 512.

From App-Note slaa281b.pdf, one can set size of MMC/SDcard block size to 2^n.

Did any one give a try with block size < 512 bytes. Or do you see any problems from MMC/SDCard/Fat-FS?

 

Thanks & regards

 

mahadevvan

[DanAndDusty 62]

I have written a library of routines for talking to SD Cards at a low level and Im working on a FAT32 compatible library.

 

The SDCARD library Ive written uses 512 byte blocks and works fine.

 

For the FAT library for program memory usage Im limiting it to only SD Cards.. NOT MMC or SDHC. From what I read SDHC cards ALWAYS return 512 byte blocks. SD Standard capacity cards can have the block size changed (Assuming the READ_BL_PARTIAL flag is set on the card). This means that you can read any block size from 1 byte upward. I *think* that you can only read with the RAM available on the valueline chips as it looks like not many cards have the WRITE_BL_PARTIAL flag set. So you have to write 512 bytes at a time. So updating the FAT table or directory entries looks VERY difficult if not impossible without an external storage.

 

The restriction on reading partial blocks looks surmountable by initiating a read of a complete block and discarding the bytes either side of the bytes you are interested in.

 

Bluehash also posted some code using someones library for talking to SDCards. If I remember right he disabled the writing code in the library. Anyways the link is Here.

 

Im planning on releasing my library into the code area of the website when Im happy with it (and I get more non xmas time and can play). My eventual plan is to use it as a springboard to learning assembler by re-writing it once Ive got it completed. I know the guts of how it works so it should be a good project to learn on.

 

Hope some of this helps.

 

Dan

[gssmahadevan 2]

Dan,

Thanks for the reply.

It seems that I can use following macro to enable writing in bluehash library.

#define _USE_WRITE 1

 

But it seems that is not possble, as bluehash has commented that no write support yet.

[bluehash 1,581]

Yes, that is correct. You can do it yourself.

Thing that are needed for write support:

1. Enable the parser to accept write commands

2. Enabling write may cause some printf functions to be used, which makes the code larger.

 

I'll fix it when I get the time.

[DanAndDusty 62]

Hmm.. Been looking at the site for Petit FS

 

Comment for pf_write says

The write function has some restrictions listed below:

 

* Cannot create file. Only existing file can be written.

* Cannot expand file size.

* Cannot update time stamp of the file.

* Write operation can start/stop on the sector boundary.

* Read-only attribute of the file cannot block write operation.

 

File write operation must be done in following sequence.

 

1. pf_lseek(ofs); read/write pointer must be moved to sector bundary prior to initiate write operation or it will be rounded-down to the sector boundary.

2. pf_write(buff, btw, &bw); Initiate write operation. Write first data to the file.

3. pf_write(buff, btw, &bw); Write next data. Any other file function cannot be used while a write operation is in progress.

4. pf_write(0, 0, &bw); Finalize the write operation. If read/write pointer is not on the sector boundary, left bytes in the sector will be filled with zero.

 

The read/write pointer in the file system object increases in number of bytes written. After the function succeeded, *BytesWritten should be checked to detect end of file. In case of *BytesWritten < ByteToWrite, it means the read/write pointer reached end of file during the write operation. Once a write operation is initiated, it must be finalized or the written data can be lost.

 

The limitations make sense to me.. To extend a file involves updating just 4 bytes in the FAT whilst preserving the remaining 508 bytes. Not easy unless WRITE_BL_PARTIAL is available on the SDCARD. Similar restriction for updating the directory entries for creating a new file or updating timestamps.

 

From looking at the code it looks like you can call pf_write with a number of bytes thats smaller than a sector and it will pad it out.

 

So if you know the size of the data you want to write you can pre-allocate the file on your PC. If you don't know the size of the file then you will need to allocate more than enough and then have your own way of detecting the end of your data.

 

Of course you could always use some external storage as a temporary storage for the data you want to preserve. The problem is that some (All the cards I have here) like CS to be active while a command/data transaction is in process. Possible solutions are

1) Have the external storage on a different set of pins (USCI_A and USCI_B for example)

2) Use something like a CD4066 to provide an ENABLE line for the SCLK to the SDCARD. That way you can disable the SDCARD and use the SPI Bus for anything else you like, then re-enable it and continue where you left of with the SDCARD none the wiser. The spec for the SDCARD interface specifies a minimum clock of 0Hz so it should all work. (This is my planned route of attack but I haven't had time to impliment it yet so no guarantees it will work)

 

As you can tell Im interested in your plans here as they parallel some of my own current plans So I would be interested in your findings.

 

Cheers,

 

Dan

[gssmahadevan 2]

Dan,

Thanks for your technical insights. These suggestions are highly helpful for my R&D with Sdcards.

I am planning to write to SDCards with SRAM <= 512 bytes. Let me see how much it goes forwar -- this I am doing in my private free time.

 

I may not be doing it really fast as I am busy with other jobs. I will keep you posted about my progress.

 

mahadevan

[gssmahadevan 2]

Finally I am able to write to SDcard write to an existing file.

Two changes were done:

* main.c: parser changes to allow write-commands to work

* Enabling _USE_LSEEK and _USE_WRITE flags to enable lseek and write in FAT-FS

 

Over next weekend, I will streamline the code and will post the code changes. I was doing following as per Petit-FS docs (and as suggested by Dan):

1. pf_lseek(ofs); 
2.1 pf_write(buff, btw, &bw); 
2.2 pf_write(buff, btw, &bw);
..
3. pf_write(0, 0, &bw);

[bluehash 1,581]

Awesome work. Thanks for finishing the work that I started.

 

One up for you!