What about Peter Lissenburg's free FAT16v2_5.zip in the files area of
this group?

Might be worth trying this before buying a commercial product ...

Best regards
Robert Imhoff

Yes it works. There is to be a release for the CodeWarrior IDE sometime this
month; we have the ImageCraft code and ran it yesterday on a Motorolas
EVB912Dpp256 eval board, to prepare for a check of the system on our PCB
prototype.,. Our Motorola eval board has wire warp wires connecting an I/F
to the SD card carrier. The demo program writes three files that Excel can
read.

For general information, if someone tries this with a wire wrap development
connection as we did, we noticed that the length of wire for the SPI signals
can cause grief on lower performance SD cards. Kingston SD cards are where
we noticed a problem; these wrote at about half the speed of SanDisk and
Panasonic in a Olympus Camera test. Our I/F wires are about 5" long and
after talking with Maxim and looking through the appnotes, any SPI signals
over 3" should be terminated signals. This cost us a lot of needless
debugging, and was very hard to figure out. Smaller cards worked but cards
over 128mb failed. I doubt that we will have the same problems on the pcb we
did for this project. All the signals there are less then 1" from the
Max3392 (spi I/F translator).

Robert Lewis
www.imotiondesign.ca

I found this to be a more useful spec file for the SPI mode:
http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf
(section 5)

Here is how I get around the FAT problem using an SD card connected to a
microcontroller as a data logger. I format the SD card on a PC (a Linux PC,
but a Windows XP system should work fine), then create one file on the SD card
as large as the card will accept (named something novel like "data"). The
file contains all zeros. This creats a FAT file directory with one file,
and the blocks in the file are sequential from the first block following the
FAT to the end of the SD card memory. The addresses of the data blocks on the
SD card are given by the 23 most significant bits of the 32-bit address word.
For a 64 MB SD card, the block addresses go from 0x00000000 through 0x03b7fe00
(the 9 LSB are always zero for the addresses). The file system information is
in blocks 0x00000000 through 0x0000be00. The first data block is at
0x0000c000. My data logger starts writing to address 0x0000c000; then goes to
0x0000c200, then 0x0000c400, and so on. After logging the data, I move the SD
card to a reader on a PC, and read data from the SD card file I created
until I get to a block which is all zeros, which indicates the end of the
valid data. This means that all of the data is in one file, but that is fine
for our application. It also means that it is easy to write the data in a
form which can be read on a PC without having to make the microcontroller
generate file system information.

--
Bill Rison
Electrical Engineering Department
New Mexico Tech
Socorro, NM 87801
rison@riso...
505-835-5486

Robert Lewis wrote:

>4) If you use FAT you will have to implement all the fopen, fclose, ....
>fputch functions that are needed in a file system, a lot of work... to say
>the least.

You can buy all of the code for the ICC12 compiler from these guys :

http://www.prllc.com/productcart/pc/viewCat_P.asp?idCategory

Has anyone tried this ?

I can give you my experience with the caveat that we approached this problem
as a full file system. Maybe this can be done in other ways, here are some
suggestions you may want to look into.

1) Check the SanDisk spec; there is a physical and functional spec on their
site. This is a link to the simplified spec; you can find the more extensive
spec if you look on the site.
http://www.sandisk.com/pdf/oem/SD_SDIO_specsv1.pdf

2) The original purpose for the multimedia card MMC, then the upgraded
secure digital card was to implement a FAT12 and finally FAT16 file system.
How you init the card is key to the way you get the data back; Windows (XP)
will not always init the card the way you think it should; in fact there is
a bug in windows (XP) that inits the card and reports it incorrectly if done
from file explorer. You need to use a DOS window. Be sure to check the init
properties of the card when you are done.
3) To implement a data log with an SD disk and then read that log on a PC,
means you will probably have to have a file system of some kind. If you are
to read the data back on a PC (unless you are prepared to write drivers that
bypass the PC File system and use your own structures) you have to use FAT.
Hence the next point.
4) The initialization process of the card over SPI (not the device/file init
in point 2) is key to getting the card to function and respond. You must use
the correct command sequence in order to have the card read and write data.
You need to consult the SanDisk spec for these commands. You want the spi
mode I think, not the parallel high speed mode. If this is a university
course project, you want to consider using the eeprom or flash instead of
the SD card. It will be much simpler and unless you are looking at large
data collections unattended over long periods of time, you can do the same
thing in flash. Just work out a transfer mechanism over a serial port, and
transfer the data more often.
4) If you use FAT you will have to implement all the fopen, fclose, ....
fputch functions that are needed in a file system, a lot of work... to say
the least.

There is no intention to dissuade you, but this is a very significant amount
of work and unless you have no other option, it could take a lot of time
starting from scratch.

The reason you are getting 3F is you are probably reading nothing from the
card, ie the lines are pulled high, or your clock is out of sequence.
Normally what is done is to run the MOSI, MISO, and SCK lines via the spi
interface, and the CS line independently with bit selection software. Assert
the CS line (active low) for the command seq write, then put the SD command
into the transmit buffer and it will clock out to the SD card, disregard the
first read, then write out another character to the spi transmit buffer to
read the cards response and so on.

Best Regards

Robert Lewis
www.inmotiondesign.ca

Hello Wayne

i'm using a 74LVC08 AND gate for the level translating, but that
probably doesn't account for any functional differences.

Are you sure you keep sending out 0xff bytes for the SPI to keep
shifting the data?

best regards
Robert

I am trying to make a little data logger that writes data to an SD card.
I am using the MC68HC912B32 processor, this has an ADG3257 on the SPI lines
to convert the 5V of the micro to 3.3V for the SD card.
I can bring the card up in SPI mode and issue a read block, the problem is
that I only get the first four bytes of the block then the card sends 0x3F
and no more data.
I was wondering if anyone else on this list has had problems like this with
SD memory cards.

Thanks

Wayne