[TUT] [C] Getting SD/MMC card working painlessly with FatFS

Go To Last Post
355 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

After following the tutorial literally as I used an ATMEGA644V, the compiling went flowlessly just the about 48 warnings mentioned in earlier postings.

But when I connected the terminal an attempted any command for example di the replies are always two weird characters ( extended characters as they are a big hexa number). I've tried different baud rates etc , always garbage. On the other side everything looks dead, not SCK activity just noisy ugly waveforms when sending any command.

So, here my first question; What clock frequency is this project using ? ( I could not find anyone mentioning this). I am using 8 MHZ internal( unset the DIV8 fuse).

I hope this could be the reason. On the other side I was using an STK500 and it is a pain to change the serial port for every try plus I must power cycle the USB adapter. I am now making a breadboard so I can use the ISP programmer and keep the same serial communication connected all the time.

I am having bad luck with SD card projects last month I've attemted the one from Roland Riegel and exactly the same poor waveforms on the SPI pins and all seems to be dead. So I disregarded on the spot as most feedback in the internet points to Elm.

The only code one it worked so far is the one on the Captain for raw access, waveforms are OK and very nice. FYI, it was EXACTLY the same hardware using ATMEGA168 than with the Roland's, so I know the problem is 100% software.

I believe my problem could also rely on the interrupts. I've never worked with interrupts ( I am scared of them)not sure whether do I need to set fuses?? Perhaps it is time to learn and get used with them.

Thanks in advance for any help anyone can throw, I will post again after retesting with the breadboard.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code bases the value it puts into UBRR on the current setting of F_CPU so you'd just need to ensure that you have F_CPU defined to 8000000UL somewhere in the project then just keep your fingers crossed that the RC inaccuracy is not sufficient to blow the baud rate out of the water.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I finally got it working. It is easier on a dedicated board than using the STK500. I am using a 2 GB Sandisk microSD.

As I mentioned, I am using same MCU as in the tutorial ATMEGA644 ( but not "p", the standard 644 which it is functionally the same). However, the original posting needs some little addittions as follows:

The F_CPU is not defined so ( Thanks Clawson) I defined it on uart.c adding:

 #define F_CPU 8000000

Above definition is using the internal RC oscillator and unprogramming the divide by 8 fuse.

I've also tried first to define F_CPU in the Makefile as

......................
PRG            = avr_mmc
OBJ            = prjELM.o uart.o xitoa.o ff.o mmc.o rtc.o
MCU_TARGET     = atmega644
F_CPU		   = 8000000
OPTIMIZE       = -Os -mcall-prologues
...........................

But it did not work, perhaps bad syntax , I am not very familiar with the makefiles.

At this point, I was not able to get the card initialized ; always got rc=1 after sending di 0 , so I overwrote the disk_initialize function as per davef post on February 3rd, but still same problem.

Then I kept reading the postings and found LyingNoise posting on March 8th that ( surprisingly) nobody else but the author replied .I realized that MISO was not defined anywhere

From the original tutorial text:

Quote:

*SPI configuration*/
#define DD_MOSI   DDB5
#define DD_SCK   DDB7
#define DDR_SPI   DDRB
#define DD_SS   4

/* Defines for SD card SPI access */
#define SD_CS_PIN   1
#define SD_CS_PORT   PORTC
#define SD_PWR_PIN   0
#define SD_PWR_PORT   PORTC 


shows that the DD_MISO is not defined. Then I tried again and after adding:

#define DD_MISO DDB6
PORTB |= (1<<DD_MISO); 

.... and , Yahoo!!!, the code is running OK and I can see directories etc. So, LyingNoise you DID were right!

What I need to retest is to go back to the original disk_initialize function to see whether the davef code is making a difference on this case or not.

kubark42 THANK YOU very much for sharing this , I know it is a lot of effort to put all this together also thanks a lot to all people posting if it were not from your postings, getting this project running would be much more difficult. I will keep testing and playing and will post if I find something useful to share.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hold on a moment . . . MISO is an input and should be set up as so from reset. Where you setting the MISO to something else before running kubark42's code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Davef,

Negative, MISO is not anywhere in the original posting. So , the code above is the only reference to it. Perhaps it needs the internal pull up ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, there has been recent postings on not forgetting to enable the pull up on this pin or the SPI can be confused about whether it is a master or slave (from memory).

I did:

// PORTB, PB0 output high, all others input pull-up enabled
// PB4, PB5 and PB7 get configured as outputs later on (SS, MOSI and SCK) 
   DDRB = 0x01;  // 0000 0001
   PORTB = 0xFF; // 1111 1111

on my ATmega 32 and there is probably even an external pull-up to be darn sure.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

not forgetting to enable the pull up on this pin or the SPI can be confused about whether it is a master or slave

That's _SS not MISO

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oops! Should have re-read those posts!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, yes, I think the problem is the pull up . In the faq questions of similar project from Roland Riegel it is mentioned to put a 50k Omhs to 3.3 volts on the DO pin of the card as one of the tips to fix initialization problems.

The only problem I am realizing now is that I am using 5 V for the AVR and activating the internal pull up may be not good in spite so far it is working fine.

I will put a 50K resistor to to 3.3V, comment out the code and try again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the tutorial, it was helpful when porting to my XMultiKit XMEGA project. You can check my implementation here:
http://www.gabotronics.com/development-boards/xmega-xmultikit.htm

And thanks to ChaN for his great FatFs library!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After a couple of evenings spitting through this tutorial and all its follow-up threads.....
I have this working on an ATMega128 running at 16MHz.

I have done
di 0
fl 0
fi
and got a responce in the form of the'good old dir command in DOS. So I assume that communication is up and running.

So first a big thanks to kubark42 and ofcoarse everybody who helped him in refining this.

I have used Rev0.07c from the FatFS system and notice that my ROM and RAm nubers aer significantly off from what is posted in earlier threads.
I now have

AVR Memory Usage
----------------
Device: atmega128

Program:   44974 bytes (34.3% Full)
(.text + .data + .bootloader)

Data:       2544 bytes (62.1% Full)
(.data + .bss + .noinit)

I have already changed the following FatFS parameter settings to try to reduce the code:

#define	_USE_MKFS	0  // not needed as I use preformatted card

#define _FS_RPATH	0 // not needed because I can write all files in the root and thus dont need directory structure

I now wonder if I can chaneg other settings in order to reduce the consumed space.
It would be nice to get the code space down a little, although I use a 128 and will have enough.
More important is the RAM space occupied. This is 2,5K out of 4K.
I have a graphical display that I can only write to, no read back, so for conveniance I have used 1K ram space to give me display RAM that I can manipulate before actually updating the display itself.
I Have an event que that I now have set to 50 events thus 100 bytes.
I want to receive GPS stuff so guestimate is 700 bytes for that
and then ofcoarse a stack.....
and then I ran out of RAM space. so that is why I would like to get the SRAM usage down

All I basically need is to be able to open a file (new and existing) and being able to write data to that file.

My guess is that if it can be run on a mega8 it should be possible to get the numbers down for me to, but I have no clue as to where to start.

just becaues of the simple fact that I'm also a relative newby in the playing feeld of embeded software

I hope someone can help me out here.

thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would TinyFat with appropriate functions disabled be any smaller?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp,

As I said in a PM, the FatFs demo program defines a [1024] byte array for "general use". There'd be no need for that in a "normal" app. Maybe [512] to hold a sector but not more. So that should drop 2.5K to 2K for starters.

I've just started doing something with FatFs on 128 too - I'll report my numbers when I have them. But the static allocation so far is nothing like 2.5K

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok,

when I have time this evening I will go and give it a try. and ofcoarse wait for your numbers. I have litterally followed this tutorial(as a relative newby). I can not imagine that you are going to do the same :)
do you also use the latest version of FatFS? or an earlier version.

thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp,

I pulled ffsampl.zip in the last few days so I'm using the very latest software (the one that merges ff.c and tff.c with the _FS_TINY switch in ff.h).

I notice that you:

di 0 
fl 0 
fi

where you are using a single drive (drive = 0) and yet the example code has:

FATFS Fatfs[2];				/* File system object for each logical drive */

to cater for two drives (0 and 1). Within the definition of the FATFS structure there is:

...
	DWORD	database;	/* Data start sector */
	DWORD	winsect;	/* Current sector appearing in the win[] */
	BYTE	win[_MAX_SS];/* Disk access window for Directory/FAT */
} FATFS;

where _MAX_SS is almost certainly defined as 512 in your ff.h

So you are reserving about 560 bytes to support a second drive you are almost bound to never use. That's be a good place to start saving memory. Simply make that [2] a [1] instead.

Also the file has:

BYTE Buff[1024];			/* Working buffer */

But Buff[] is only used in the commands

dd (dump sector - 512 bytes used)
ds (disk status - only 64 bytes used)
bd (buffer dump - just 512 bytes)
be (buffer edit - variable length usage)
br (buffer read - 512 * number of sectors)
bw (buffer write - 512 * number of sectors)
bf (buffer fill - sizeof(Buff[]))
fr (file read - limited to sizeof(Buff[]))
fd (file dump - depends on given 'len')
fd (file write - depends on given 'len')
fx (file copy - done in chunks sizeof(Buff[]))

Soo, there's room there to reduce the size of Buff[], maybe reducing it from 1024 to 512 would be the first step. Beyond that you'd need to re-work the implementation of some of those commands or prevent their use all together.

With those two changes alone you should be able to knock 1,072 bytes off your RAM usage.

But the whole point of the "monitor" example is that it is just that - an example. It allows pretty much everything in the API to exercised . But in a "real" app you will probably use a subset of the functionality with a more limite RAM requirement. Though you are going to need one FatFs[] entry and almost certainly one 512 byte buffer. A bit over 1K.

You can see this in the Application note:

http://elm-chan.org/fsw/ff/en/ap...

Notice the D and F values. A minimal system could work with D=1 and F=1. So for _FS_TINY this would mean just 560+32 and for non-Tiny operation 560+544 - a bit over 1K

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

thanks for this clear explenation. I'm sure that more people in the future will benefit from it. I will try it as soon as possible. I forgot to take the code with me this morning :( so can not try it quickly on my work.

Regards

Marcel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Marcel,

Well I think you will expect to get something like:

AVR Memory Usage
----------------
Device: atmega128

Program:   29826 bytes (22.8% Full)
(.text + .data + .bootloader)

Data:       1790 bytes (43.7% Full)
(.data + .bss + .noinit)

Cliff

(my code is slightly larger than expected as I already have my own UART and LCD support added)

PS what that 1790 figure (and your own figures) don't show is:

int main (void)
{
...
	DIR dir;				/* Directory object */
	FIL file1, file2;		/* File object */

and each of those FIL structures (unless _FS_TINY is defined) will contain another 512 byte sector buffer. So there's more than 1K more of SRAM being used there too that is not shown at build time. Personally I think it is an argument for moving those FIL's out of main() and making them global so they "show up" at build time. By the way "file2" is ONLY used to support the fx (file copy) command. So if you can live without that remove "file2" and "#if 0" the case' 'x' where it's used.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How very annoying. I just spent a rather unhappy couple of hours adding printf()s and driving each control line in turn, checking wiring with a meter and so on to try and track down why I wasn't getting the 0x01 response to CMD0. All the control lines seemed to be connected and drivable/readable (including card inserted and write protect). The only I/O I didn't check was PE7 which I was using to switch Vcc to the card. As the SD socket from www.futurlec.com has a power LED I was pretty sure at least that bit was working.

Except it wasn't.

The Chan example code has:

	PORTE = 0b11110010; // Port E
	DDRE  = 0b10000010;

and mmc.c has:

static
void power_on (void)
{
	PORTE &= ~0x80;				/* Socket power ON */

and

static
void power_off (void)
{
...
	PORTE |=  0x80;			/* Socket power OFF */

It only took me about 2 hours to realise that all this is the "wrong way up" (because Chan's example circuit uses PE7 to switch a transistor off and thus inverts the sens of it). What was actually happening was that each time the card was accessed the power was momentarily being turned off, not on.

But finally I got to:

>FatFs R0.07b test monitor for AVR
>di 0
rc=0
>fi 0
rc=0 FR_OK
>fl
D---- 2007/06/01 18:44         0  DCIM
----A 2008/04/09 08:24       296  WMPINFO.XML  WMPInfo.xml
D---A 2009/01/18 17:38         0  20GREA~1  20 Greatest Hits
D---A 2009/01/28 10:44         0  CARPEN~1  Carpenters Gold
D---A 2009/01/18 17:48         0  CLASSI~1  Classic Experience (Disc 2)
D---A 2009/01/18 17:48         0  CLASSI~2  Classic Experience II (Disc 1)
D---A 2009/01/18 17:49         0  CLASSI~3  Classic Experience II (Disc 2)
D---A 2009/01/28 10:45         0  DARE!  Dare!
D---A 2009/01/18 17:55         0  HEARMY~1  Hear My Song (Best Of Josef Locke)
D---A 2009/01/28 10:45         0  JOSHUA~1  Joshua Tree
D---A 2009/01/18 18:09         0  ONEORI~1  One Original Step Beyond - The Story Of Ska
D---A 2009/01/18 18:10         0  PAINTI~1  Painting It Red [Expanded]
D---A 2009/01/28 10:47         0  PRINCE  Prince
D---A 2009/01/18 19:03         0  WAROFT~1  War of the Worlds
D---A 2009/01/18 19:02         0  VIVALD~1  Vivaldi_ The Four Seasons
D---A 2009/01/18 18:59         0  THISIS~1  This Is SKA - The Famous And Infamous
D---A 2009/01/18 19:00         0  TRUECO~1  True Confessions
D---A 2009/01/28 10:47         0  QUEENG~1  Queen Greatest Hits [UK CD]
----A 2007/11/08 21:07   2255368  TORAMO~1.WMA  To Ramona.wma
   2 File(s),   2255664 bytes total
  17 Dir(s),     324320K bytes free
>

So I'm now a happy bunny.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, does anyone else have problems with some SD not responding to initialisation:

Sandisk 128MB - No
"integral" 1GB - Yes
Tesco 4GB - Yes
Kingston 16GB - No
no-name 1GB - Yes
Kingston 2GB (micro SD in carrier) - No

I've tried defining the FCLK_SLOW:

#define	FCLK_SLOW()		(SPCR |= ((1<<SPR0)|(1<<SPR1) ))

which for F_CPU=8MHz should select /128 to run the SPI at 62.5kHz - actually too slow but I get the same with /64

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

I have had a few minutes to play with your described settigns.
The code space still was around 47K, but that was including the entire terminal application. The memory space I reduced to 1350Bytes. I decreased the _MAX_LFN parameter to a lower value. It is used for long filename support( want to use that) and as far as I could tell it is teh max number of characters a file name may be. As i intend to always use a format of date and time + extension I could reduce this number and save some more bytes.

btw nice music choice :)

Thanks for telling about the additional memory usage. I will have to keep that in mind.

regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

I am trying there guide in geting the FatFs working, but i am getting some problems.

Mojority of the errors i get are repeated, so i presume all route to same area.

Quote:

E:\AVR_Project\CHIP\FAT\ffsample\avr\default/../main.c:584: undefined reference to `xatoi'
E:\AVR_Project\CHIP\FAT\ffsample\avr\default/../main.c:570: undefined reference to `xprintf'
E:\AVR_Project\CHIP\FAT\ffsample\avr\default/../main.c:243: undefined reference to `xfunc_out'
E:\AVR_Project\CHIP\FAT\ffsample\avr\default/../main.c:245: undefined reference to `xputs'
E:\AVR_Project\CHIP\FAT\ffsample\avr\default/../main.c:248: undefined reference to `xputc'

And warnings

Quote:

../main.c:322: warning: pointer targets in passing argument 2 of 'xatoi' differ in signedness
../main.c:318: warning: pointer targets in passing argument 1 of 'get_line' differ in signedness
../main.c:249: warning: pointer targets in passing argument 1 of 'get_line' differ in signedness

DJ

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The "x" functions are in xitoa.S - make sure this is added to the list of files to be built in your project

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks i remember i have not included the file, so i will added it in the eveneing.

Thanks

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The errors have gone, but i am getting 50 of the warnigns as shown below

Quote:
../main.c:515: warning: pointer targets in passing argument 2 of 'xatoi' differ in signedness

Quote:
e:/program files/winavr20090313/lib/gcc/../../avr/include/util/delay.h:85:3: warning: #warning "F_CPU not defined for "

By the way why is there a UART, i though the code uses SPI and not the UART ports.

DJ

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

i am getting 50 of the warnigns as shown below

If you are worried about that it suggest you haven't read the whole of this thread.

I actually went to the trouble of fixing up all the warnings (by changing a lot of "char" to "BYTE") but it's benign

The UART in the demo program is for you to control the demo. It presents a command prompt and (again as documented in this thread) you type commands like "di 0", "fi 0", "fl" etc.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So i presume it still works with all the warnings

DJ

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With USART i presume i need the terminal on the PC, if i want to avoid all this a write test file, can this be done with the download recommened, as the guide does not show this.

DJ

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a sample cod e that is known to work that creates a file and writes hello.

This way i can test that everything is ok in terms of connection etc.

DJ

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

That's a benign warning - ignore it.

What does Benign mean?
Quote:
../main.c:544: warning: pointer targets in passing argument 2 of 'xatoi' differ in signedness

So code can work and i dont need to worry about all these warnings? Right?

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What does Benign mean?

From the Merriam-Webster dictionary:

having no significant effect, harmless

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you really want to know it all hinges around the fact that there are three types of char.

"char", "signed char" and "unsigned char".

"char" is neither signed nor unsigned. A constant string like "Hello, world" is of type char. If you pass this to a routine declared to use "signed char" or "unsigned char" you will get a warning about "differ in signedness".

On the whole this does not matter but if you worry about this then, like I say, you can add typecasts and change "char var"'s into "BYTE var"'s as I did (BYTE is "unsigned char")

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:
Is there a sample cod e that is known to work that creates a file and writes hello.

This way i can test that everything is ok in terms of connection etc.

DJ

Not... per se. However, if you follow the tutorial precisely, it will lead you to an area where you can read and write, just by following the instructions in the example. In any case, this is something you need to do before going any further, as, as many have pointed out, some SD cards don't respond to the initialization. There's no sense in you wasting time pulling out your hair over a card that's borked.

I suggest that you follow the tutorial line by line. I did my best to write it as clearly as possible, and normally there is not one single thing that is left unsaid for getting it up and running on a bog-standard AVR and SD socket. (Of course, if there is anything unclear, just let me know and I'll do my best to fix it.). Again: follow it LINE BY LINE.

Hope it works for you!

Cheers,
Kenn

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
How very annoying. I just spent a rather unhappy couple of hours adding printf()s and driving each control line in turn, checking wiring with a meter and so on to try and track down why I wasn't getting the 0x01 response to CMD0. All the control lines seemed to be connected and drivable/readable (including card inserted and write protect). The only I/O I didn't check was PE7 which I was using to switch Vcc to the card. As the SD socket from www.futurlec.com has a power LED I was pretty sure at least that bit was working.

Except it wasn't.

The Chan example code has:

	PORTE = 0b11110010; // Port E
	DDRE  = 0b10000010;

and mmc.c has:

static
void power_on (void)
{
	PORTE &= ~0x80;				/* Socket power ON */

and

static
void power_off (void)
{
...
	PORTE |=  0x80;			/* Socket power OFF */

It only took me about 2 hours to realise that all this is the "wrong way up" (because Chan's example circuit uses PE7 to switch a transistor off and thus inverts the sens of it). What was actually happening was that each time the card was accessed the power was momentarily being turned off, not on.

I hadn't realized there were a new version of FatFS. Not having looked into it yet, I can't say whether my tutorial needs updating or not. Cliff, do Chen's changes break my tutorial?

Kenn

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kenn,

I *think* there are changes which might have a bearing. Somewhere in this thread someone said something about needing to add code in the initialization to slow things down. Yet the newer code seems to have a macro FCLK_SLOW() at the salient places. I imagine there may be other such improvements in 0.7c

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good tut. I got it working on a mega644 of my own.

I'm attempting to read an mp3 off a SD card and feeding to a VS1002 mp3 decoder chip. IM a long ways away from that but I gota start somewhere. I'm trying to understand the process of making file data present on the Atmega from a terminal (for now).

I believe it goes something like this, Correct me if im wrong please:

Initialize disk - di 0
Mount the drive - fi 0
Open the file, mode 3 for read - fo 3 1.mp3
read the file - fr 512

I think that would make the first 512 bytes of the file present in Buff[] for me to do with what I want, which in this case would be to send it to the VS1002 for DAC. Is that process correct?

You don't gno-me!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
By the way, does anyone else have problems with some SD not responding to initialisation:

Sandisk 128MB - No
"integral" 1GB - Yes
Tesco 4GB - Yes
Kingston 16GB - No
no-name 1GB - Yes
Kingston 2GB (micro SD in carrier) - No

I've tried defining the FCLK_SLOW:

#define	FCLK_SLOW()		(SPCR |= ((1<<SPR0)|(1<<SPR1) ))

which for F_CPU=8MHz should select /128 to run the SPI at 62.5kHz - actually too slow but I get the same with /64

Cliff

Could this be due to current requirements making the voltage sag? I realized that in my original tutorial, I recommend using the AVR output pin for voltage. In retrospect, this isn't at all what I do in practice, as I've connected the card straight up to the 3.3V rail. These SD cards tend to pull a lot of amps (relative to the rest of a uC circuit), and so these problems might be more due to insufficient current supply rather than inherent card incompatibility. If you still have those cards lying around, why not start adding some capacitance to the V_in at the SD card and see if anything improves?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If you still have those cards lying around, why not start adding some capacitance to the V_in at the SD card and see if anything improves?

Great idea - but for starters I'll just jst use a high current PSU direct as I think that is the issue. Another approach would be to use several IO pins to power the card to share the current load.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
CAVEAT!!!:
Quote:
You MUST use 3.5V or less on both the SD card, and the SPI lines. If your chip is already running at <3.5V, great, otherwise you NEED level converters. Don't be mad at me if you blow up your SD card because you gave it too much juice. (They like 3.3V, but will tolerate 3.5V.)

Folks, what's the best way to go from 5V to 3.3V per the above? Diodes/resistors/DC-2-DC stepdown IC? Appreciate for specific details.

Btw, FatFS is GPL?

Thx

Last Edited: Fri. Oct 16, 2009 - 04:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In their mini-board range Futurlec have:

http://www.futurlec.com/Mini_Log...
and
http://www.futurlec.com/Mini_SC....

Or if you want to do it yourself then just borrow the design of that 74LC245 based board.

Or there is, of course, the option of running everything (including the AVR) at 3V3 in the first place. (except that the speed junkies may baulk at possibly having to run the AVR slower - God forbid!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

unebonnevie wrote:
Quote:
CAVEAT!!!:
Quote:
You MUST use 3.5V or less on both the SD card, and the SPI lines. If your chip is already running at <3.5V, great, otherwise you NEED level converters. Don't be mad at me if you blow up your SD card because you gave it too much juice. (They like 3.3V, but will tolerate 3.5V.)

Folks, what's the best way to go from 5V to 3.3V per the above? Diodes/resistors/DC-2-DC stepdown IC? Appreciate for specific details.

Btw, FatFS is GPL?

Thx

Definitely NOT a resistor. You'll apply 5V to the chip until the current starts moving. I'm not sure if you'll fry some things or not, but I wouldn't want to try it.

I just run my uC at 3.3V. That's a much easier way of doing things for me. Of course, you could make a transistor bank in order to level shift, or just get one of those MAX level shifters.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Btw, FatFS is GPL?

ff.h just says:

/  Copyright (C) 2009, ChaN, all right reserved.
/
/ * The FatFs module is a free software and there is NO WARRANTY.
/ * No restriction on use. You can use, modify and redistribute it for
/   personal, non-profit or commercial use UNDER YOUR RESPONSIBILITY.
/ * Redistributions of source code must retain the above copyright notice.

Which sounds more like a BSD licence to me though I don't think he actually names one of the well known licences as such.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a schematic that shows how to get the SD card to 3.3V.

http://www.olimex.com/dev/images...

Urggg...Sorry, not really. :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

unebonnevie wrote:
Here is a schematic that shows how to get the SD card to 3.3V.

That schematic uses 3.3V for the microcontroller. While I'm certain that it will be useful for anyone hoping to hook up a 3.3V card, I think it confuses the question at hand, which is how to hook it up to 5V.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello

Clawson gave me the hint to this tutorial and i have a quesition:

#define DD_MOSI   DDB5
#define DD_SCK   DDB7
#define DDR_SPI   DDRB
#define DD_SS   4 

Where ist the pin-declaration for the MISO-line?
Is there a difference between for example DDB5 and PB5?
Do i need the SS for my ATmega(on my AVR it's NC)?

And what is with the FCLK-Settings?

Thank you

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

He's only using those defines to set the bits in the DDR that are outputs (by default the rest are inputs) so by not specifically setting MISO it'll just be left as an input.

To be honest the point he's making is that this is not the cast in stone way it MUST be done but simply that what exists in power_on() must match the way the hardware has been wired up. As you'll see Chan simply did:

	PORTB = 0b10110101;			/* Enable drivers */
	DDRB  = 0b11000111;
	SPCR = 0b01010000;			/* Initialize SPI port (Mode 0) */
	SPSR = 0b00000001;

without any fancy naming of the individual bits. Though it's true that you have to sit down and study this in conjunction with that avr_mmc.png picture quite a bit to spot what he's actually doing.

avr_mms.png shows Chan using a 9.216MHz crystal but you aren't tied to that - the key point is that if you use a very fast F_CPU (like 16 or 20MHz) then you may need to implement the FCLK_SLOW() macro to slow down the SPI during the start of initialisation. Just for "belts and braces" I used:

#define	FCLK_SLOW()		(SPCR |= ((1<<SPR0)|(1<<SPR1) ))	/* Set slow clock (100k-400k) */
#define	FCLK_FAST()		(SPCR = 0b01010000)					/* Set fast clock (depends on the CSD) */

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a schematic to show how to have 3.3V for the MMC/SD card.

http://www.mikroe.com/pdf/mmc-sd...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So some cards doesn't seem to work.
But how does a cardreader for the PC manage the cards? The procedure of initialization and so on is the same. Then where is the difference?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anybody made this work on Olimex AVR-TLCD-128CAN development board?

I am simply trying to get the file names up on the LCD screen, but it seems that the Finfo is empty although I put several files on the card using the PC and formatting the card to FAT. Where to start debugging?

I skipped completely the UART part since I am not using a console, might some definition their be the reason, although everything is compiling without errors?

Regards,
P.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ratep2001 wrote:
Does anybody made this work on Olimex AVR-TLCD-128CAN development board?

I am simply trying to get the file names up on the LCD screen, but it seems that the Finfo is empty although I put several files on the card using the PC and formatting the card to FAT. Where to start debugging?

1)Try formatting the CARD with Ms-Dos (Select the Cluster size according to the File System you have implemented).

2)If the connections are correct it will work.
3)To start Debugging ,Check if MBR loads successfully.
4)Have you selected the right Crystal and whether correct power supply is given its 3.3 V by default.
5)I have tried this code on a SD-CARD having memory upto 512 Mb.

6)If it still doesn't work i will suggest try it on SD-CARD of some other company.
This codes works fine with ScanDisk(64MB) and Nokia(128 Mb)

B'Regards
Dakudiv :twisted:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Get a copy of WinHex on your PC and use it to explore the key sectors in the file structure (MBR, BPB, FAT entries, root DIR). Then add debug to the FatFs code to show the sector contents after each of these key sectors is reads and make sure it's seeing the same thing and interpreting it properly.

Pages