SD memory card what is the dirty little secret.

direnc · Joined: 28 Jul 2004 Posts: 5

Please ignore the last question. I have figured out what's going on. I have been editing the logical drive insted of the physical drive.

aekalman · Joined: 31 Jul 2004 Posts: 2

Hans.

I'm a bit late to the party, but maybe I have some insight ...

1) The main marketing point about SD is that it's "4x faster" than MMC. That's because it can handle four concurrent data streams (though not in SPI mode). I wonder if this "feature" impacts the BS/FAT in SPI mode ...

2) Is it correct to say that your problems do not occur on cards 64MB or greater?

--Andrew

Hans Wedemeyer · Joined: 15 Sep 2003 Posts: 226

aekalman · Joined: 31 Jul 2004 Posts: 2

Hi Hans.

Thanks for your reply.

I didn't mean so much that it was faster. Rather, I meant that perhaps the "concurrent operation" of the SD spec is achieved by some trickery / nonstandard stuff re the boot sectors, etc. within the SD spec. And that is itself the root of your problem. Of course, all of this is strictly conjecture on my part.

Did you use the FlashFile (AVR) stuff from prllc as the basis for your code?

I'm facing a similar problem (want to run SD on the MSP430 via SPI), and I feel that as MMC disappears and is replaced by SD, it's wise of me to standardize on an SD connector and SD cards. I can live with a size requirement (e.g. my users must use 64MB or larger SD cards), so I may not be as sensitive to the FAT12/FAT16 issue as you are ...
_________________
--Andrew
aek at/ pumpkininc dot// com

Hans Wedemeyer · Joined: 15 Sep 2003 Posts: 226

MGP · Joined: 11 Sep 2003 Posts: 57

TSchultz · Joined: 08 Sep 2003 Posts: 66 Location: Toronto, Canada

If you check out ARV freaks, I know the competition. There is are open source routines for FAT16/32 with read and write support. There are also drivers for SD/MMC cards that work quite well. There are a few small problems with the FAT drivers but they are easily fixed and will be released in a newer version. These are written for the GNU GCC port for the AVR. They have full directory support and have all the necessary functionality if you do not need long file name support.

I have the drivers working with an MMC card in an industrial test equipment application where I needed full write support. The biggest problem with using these on the PIC may be the RAM requiements, around 1.3KB. They could the ported quite easily.

I am currently in the process of porting the working routines I have to the TI MSP430 and then to the Zilog encore family. I will probably work on a port the PIC under CCS once I have a need for them.

Guest · Posted: Tue Dec 28, 2004 5:51 am

Did have some simular problems, strange behavior of memmory cards. I was using MMC ones and they got bad after corrupt writes when used in own hardware. After this the MMC cards could no longer be read in a PC/windows USB card reader.

In the end I managed to work around it, but not fond/solve the problem.

check this site, some info about SD card problems.
http://sdprob.aximsite.com/

re Me

TSchultz · Joined: 08 Sep 2003 Posts: 66 Location: Toronto, Canada

I have had a few problems with a couple of MMC cards, but I have been able to "fix" them. It seems that the partition table can be easily corrupted in these things and depending on what you have for tools creating a new table is a problem.

Under Linux I have been taking a full binary image of the entire device. I am able to write this back to the card if things get corrupted. This image and a good hex editor has also been invaluable in troubleshooting some of the more subtle directory issues.

Mostly the corruption came from problems with the driver, although I have since seen a corrupted card with read-only routines running on it. Not sure what happened here. To make things stranger a Toshiba laptop was able to read/write to the card, but the partition type was invalid when I checked the binary image.

jimp · Guest

All,

I am using an SD Card with a PIC microcontroller. Is it possible to be able to suspend the clock going to the SPI I/F while I do something else such as an interrupt, and after the interrupt returns, go back to clocking the SPI I/F again, without losing data or running into timeout problems?
I would appreciate a response one way or the other as I have been searching for this info for about a week or so, and cannot find anything definitive. I want to ask before I change ny firmware because it's working fine now and I would like to be able to suspend the clock signal as a way of implementing some future features. I can't say what the features are at this point, but would like to knopw about suspending the clock. Any answers would be greatly appreciated. You can contact me offline at jim@jpes.com.

Thanks and Regards,

Jim