I would suggest not. This thread is about getting FatFs to work on an AVR. Only post things here that might help future users of FatFs achieve that goal. If you have a general question about filing functions and especially about PC filing then post that elsewhere. If it is about AVR then post it in the AVR Forum. If it is a general question then put it either in "General Electronics" or "Off Topic".

Actually i wanted to let you know that i have created a program which can Create a file, overwrite a file, add more data to a file and lastly read the file.
I am getting this error when i post the code:

Quote:

Bad Request

Your browser sent a request that this server could not understand.

This is the code if you are interested. It is working perfectly except that if u enter any alphabet instead of number as choice to perform operations, the program goes mad.
Now i wanted to know is this much basic understanding enough to move back to avr and the fatfs?

Now i wanted to know is this much basic understanding enough to move back to avr and the fatfs?

Yes, you can see exactly the same concepts there that you will use in FatFs. In FATFS "FILE" is effectively "FIL" and most of the functions start "f_" rather than just "f". Also the parameters are a little different but in effect achieve the same things. The key thing you learnt is that you create files with fopen/f_open and the same is later used to reopen files you already created. You write with fputc, fputs, fwrite and FatFs has f_putc, f_puts and f_write. You read with fgetc, fgets, fread and FatFs has f_gets and f_read but strangely no f_getc (though Chan does the equivalent with f_read(fp, s, 1, &rc); inside f_gets so you could either implement a function or just #define an equivalent for f_getc). In DOS you close the file with fclose, in FatFs it is f_close. If you want to move to a particular place in a file in DOS it is fseek while FatFs uses f_lseek.

On the whole this means you can throw together a quick DOS filing program on the PC to test out an idea (like how do you sort the lines in a file say) then you can implement it in almost identical FatFs functions on the AVR and be pretty sure the same logic is going to work.

Now i wanted to know is this much basic understanding enough to move back to avr and the fatfs?

Yes, you can see exactly the same concepts there that you will use in FatFs. In FATFS "FILE" is effectively "FIL" and most of the functions start "f_" rather than just "f". Also the parameters are a little different but in effect achieve the same things. The key thing you learnt is that you create files with fopen/f_open and the same is later used to reopen files you already created. You write with fputc, fputs, fwrite and FatFs has f_putc, f_puts and f_write. You read with fgetc, fgets, fread and FatFs has f_gets and f_read but strangely no f_getc (though Chan does the equivalent with f_read(fp, s, 1, &rc); inside f_gets so you could either implement a function or just #define an equivalent for f_getc). In DOS you close the file with fclose, in FatFs it is f_close. If you want to move to a particular place in a file in DOS it is fseek while FatFs uses f_lseek.

On the whole this means you can throw together a quick DOS filing program on the PC to test out an idea (like how do you sort the lines in a file say) then you can implement it in almost identical FatFs functions on the AVR and be pretty sure the same logic is going to work.

I certainly have some understanding now, in fact now i know what line is doing what in the code you gave. (reads poem.txt) Btw what is the FRESULT ? and why it turns blue...

So i guess now its basically trying out different commands of the library but i have still a confusion. Like in the code i made, it is quite easy to perform File operations. But in FATfs we are dealing with an SD card, so does the library handles the SD card itself? Like after it is initialized, do i just have to make a code for File operations or do i need more commands apart from f_ commands?

If it turns blue I guess you are using AS6? If so you can always put your cursor on any word in the code, right-click and "Goto implementation" to find out what an object is and how it's defined. For FRESULT you will find:

So each of the f_*() function you call might return any of these numbers to indicate whether it worked (FR_OK==0) or if there was a problem (!=0). For example if you call f_open() to read a file and it's not there you might get FR_NO_FILE. This highlights the fact that each time you call an f_*() function you should test the return value and only proceed if there was not problem. Something like:

This way you only go on to do the f_gets() if the f_open() succeeded and you only go into the code beyond the f_gets() if that succeeded and so on.

Quote:

But in FATfs we are dealing with an SD card, so does the library handles the SD card itself? Like after it is initialized, do i just have to make a code for File operations or do i need more commands apart from f_ commands?

You can do everything with f_*() commands thought it is VITAL that the very first f_*() function you call is f_mount (and CHECK the FRESULT!). The f_mount is perhaps the one place where FatFs filing differs from DOS/Unix filing because in those systems the filing system is already mounted (though Linux uses may well be familiar with "mount" and etc/fstab which is something you do before running a program to access files on a drive). In the AVR there is no operating system so it's your program's responsibility to start by mounting the file system (which basically means "initialise everything so we're ready to read/write").

However note that he is actually doing something a little unusual here. He has a system with TWO SD/MMC cards connected so he has to call mount twice. As most of us only have one SD/MMC attached to our AVRs we generally only need to make one call to the f_mount function.

Just checked back in after my post of 12/5/2012 got no replies for several months. So, I assumed that very few people had tried using the latest code from Chan and that the older code on which the original tutorial based was no longer available. I had many projects in progress, so tabled getting the SD hardware working on a couple of cards until I had more time.

Thanks meslomp for your write-up and Clawson' April 11 and June 22 updates!

I printed and read again all 62, double sided pages on this topic. It looks pretty straight forward starting with the June-22 AV6 project and the few posts that are actually relevant to me post 1 to now.

I see conflicting information about the code size on something like an Atmega328, so I might run into trouble there.

Testing using the main.c provided in the June 22 Clawson post. My hardware doesn't have a way to display UART output, so I right now I just turn on an LED if the f_open succeeds.

It didn't until I put a poem.txt on the SD (using my laptop). So, I think that's a good start.

I need to write to the SD, so I'll figure a test case to write a hello world on the SD and see if that works.

But, I think I do have an issue with my board. The SPI is used on another device and I swapped the CS I planned to use for the SD with that of the other device. So, the SS pin goes to the other device and PD4 is actually the CS for the SD card.

I'm "bit-banging" the SPI for the other device. I think I'll have to do this for the SD card too. Otherwise, the required SS pin toggles will mess up the SPI hardware module.

So, I'm debating whether I should just turn another card, or just bit-bang the SPI for SD access too. Speed isn't an issue for my application, since all the data that will be written to the card comes from a 4800 baud serial interface.

Also, the FatFs code just blocks waiting for SPI completion, so it's not like use of the SPI hardware on the processor is any better than bit-banging.

There's also some "flakiness". After programming, I have to remove the power to get through the code and light my "success" LED. Just doing a reset isn't sufficient. Maybe has to do with the other device on the SPI, though the test case should be keeping it off the SPI by holding its CS high.

Also, someone mentioned in one of the posts that he had to remove the SD card when ISP programming? I understand why that's necessary if an external pull-up isn't used on the SD CS, since all outputs of the processor to to Hi-Z when the part is in reset. So, the SS pin could drive low or get capacitively bounced active.

I've had that issue on other cards with SPI peripherals and fixed by adding an external pull-up..

If SPI devices are CS is held inactive (high), even during reset using an external pull-up, should the SD card interfere with ISP (mine doesn't seem to).

I don't know what i'm doing wrong ...
I try it for 3 weeks to make the fat fs working ... no susces.
I'm using an atmega328p at 12Mhz
on portc 0-1-2 have an rgb led for debug.
portb 0 ->CS
portb 5 ->SCLK
portb 4 ->MISO
portb 3 ->MOSI
i've failed with the fool_proof example from witch i have seen it's using bitbanging.
Anny help is welcome
sdmmc.c

I've manage to write files on SD! I'm using the SPI routines for sdc card, and finally .. it's working!!! I changed to the 20 Mhz crystal, setting up TIMER2 CTC to obtain 100Hz. I don't know why but bitbanging sd card didn't worked for me ... Now I'm trying to play an wav file ... timer0 fast pwm , timer1 ctc mode with variable OCR1A from wav ... I will compare the first post of the thread and put the changes that i've been made to the code, if I found differences . :)

I have ATMEGA32 with 8MHz internal oscilator i connected everything, coppy files from avr_complex sample(ff.c, ff.h, diskio.h, integer.h, mmc.c, ffconf.h) and i just change the mmc.c on my ports in macros and power functions but the problem is further:

1) Have you plugged the cards into a PC and downloaded a copy of WinHex from Xways software (the read-only version is free to try)? It will confirm what filesystem the cards actually have. Is it FAT12, FAT16, FAT32 or something else?

2) do you own/have access to an oscilloscope or logic analyser? There's nothing quite like it for diagnosing the operation of SPI.

In FatFs the checks made that might return FR_NO_FILESYSTEM are as follows:

Prior to that is a call to check_fs() which should have returned 0 if it found the AA55 signature of an MBR or BPB. I'd suggest, with the aid of WinHex working through each of those tests in turn and assuming the cards do have a FAT filing system find out which of the policed rules is being violated.

Alternatively either breakpoint each of those return points if you have a JTAG debugger or put some diagnostic code (UART, LEDs, whatever) at each point in your local copy of ff.c and find out exactly which of those rules is violated.

In Chan's documentation, he frequently uses the word "collapted." For example in the description of disk_initialize() this appears:

Quote:

Application program MUST NOT call this function, or FAT structure on the volume can be collapted. To re-initialize the file system, use f_mount() function instead. This function is called on volume mount process by FatFs module to manage the media change.

I have been using FATfs with an ATmega1284P and an SD card via the hardware SPI, and it works fine.

I am working on an MP3 player using the 1284P and a VLSI 1063 DSP which allows me to output a 44.1 KHz Mp3 to a Class D amplifier in the I2S format. My first attempt used the hardware SPI to communicate with both the SD card and the DSP. This did not work fine. Probably because of the fairly slow access time to the SD card over the SPI.

So, I decided to use the second SPI available on the 1284P, which is an MSPI, or a USART converted to use as a SPI. This seemed like a good solution, because I could use the MSPI to acquire data from the SD card and, simultaneously, send it to the DSP with the SPI, interrupt driven.

The problem, is that I have not been successful making the MSPI talk to the SD card. I altered the FATfs file mmc.c for the MSPI as shown in the attached file.

I was hoping that someone might have done this and recognize why FATfs reports FR_INVALID_OBJECT when I try to access it with the MSPI, but works fine when I use the SPI. The code that calls the SPI(MSPI) is the same in either case, so the problem must be in mmc.c.

The MSPI acts normally, I get CS, MOSI, MISO and SCLK on the scope. The return value of disk initialize is 0. It pounds out the dummy bits and there appears to be an answer back from the SD card. But when I f_open, I get res = NO_FILE_SYSTEM. If I take exactly the same code, but swap out the mmc.c file back to the one using the regular SPI, I get FR_OK and I can read the MP3 file without any problem.

I was just hoping that someone else had done this and seen the same problem. Its probably some little glitch that I am missing.

A follow up on this. The two SPI's work fine if you use the MSPI to send data to the codec, and use the SPI communicate with the SD card. I do not know why, but for some reason, FATfs doesn't like the MSPI. Using both SPI's vastly increases the data rate you can send from the SD card to a digital signal processor using FATfs.

I'd be very surprised if FatFs held ANY kind of opinion about any hardware device. If the device works like an SPI then FatFs simply works. If it didn't then it's because the MSPI was not behaving entirely like an SPI, FatFs's opinion didn't count.

I have no skills about communication between microcontroller and sd car but i want to writing data from my temperature sensor ds18b20 into the sd card.
I'll capture the temperature from sensor for example every 1 miunute and this value i want to put into csv file on every line for each value at every one minute.
I wonder whether is this hard to do with this FatFs library.
I am using atmega16 mcu and I appreciate of any help and suggestions.
TNX

I am using AVR studio, i don't know at first how should i begin with this.
At the beginning i downloaded fatfs library from this page:http://elm-chan.org/fsw/ff/00index_e.html
I was importing all files in map ffsample/avr-toolproof into avr studio and compiled the code, it was successsfuly.
Now i must organize all code that it will compatibile with atmega16 MCU and then try to write somenthing into sd card...

I you missed it and just posted a question here because the posts seems to be about SD card: The first page of this thread start out with a tutorial about exactly this.

Have you read it?
Have you tried to repeat what is done in the tutorial?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Also don't just read the first post/page, FatFs has developed and so has this thread so read all 17 pages.

Note that mega16 with just 1K of SRAM can be "tight" for FAT work. Consider trading up to a larger micro (mega32?) or consider using the "petit" version of FatFs. Also don't just read the first post/page, FatFs has developed and so has this thread so read all 17 pages.

Note that mega16 with just 1K of SRAM can be "tight" for FAT work. Consider trading up to a larger micro (mega32?) or consider using the "petit" version of FatFs. Also don't just read the first post/page, FatFs has developed and so has this thread so read all 17 pages.

Note that mega16 with just 1K of SRAM can be "tight" for FAT work. Consider trading up to a larger micro (mega32?) or consider using the "petit" version of FatFs.

EDIT: Wow what happened in this post? I didn't type that multiple times so something went wrong when I posted it?!?

I just try to write a test program from page mentioned above in MCU and works great!
The program has created a txt file and write some words into it.
My next goal is write data to csv file as described.

If someone of you working on sime kind of data logging with sd card using FATFS library?
I want to write data (temperature for example ) in csv file every 1 minute and each of data should be written in separate line.

F_CPU has very little to do with FatFs anyway. The only place timing really comes into things is that you should have a 100ms timer used for timeouts and to scan the card present and write protect state but if the timing is off a bit it doesn't really matter. If you have problems they are more likely elsewhere. It can help a lot to have a scope or logic analyser to check the SPI signals are doing what you expect.

Yeah that should be quite possible. As this whole thing has hopefully shown the actual dependency on hardware interaction in FatFs is actually really small and the good news is that it's pretty much all isolated into mmc.c (in the ffsamp-jun22 files - later it is called mmc_avr.c). It just consists of using the SPI and a couple of IO pin (card detect and write protect sensors). So that's pretty much the only "porting" required to move this to Xmega. Just compare the tiny/mega way of doing those things (SPCR/SPDR/SPR/DDR/PORT/PIN) with the Xmega way of doing it and make adjustments accordingly. The only other "hardware interaction" that will need to be changed is the setting up of a timer interrupt - you need to set a timer to 100Hz /10ms and it should call Disk_TimerProc() each time the interrupt occurs.

But that is ALL you have to change. Everything else in FatFs is completely independent of the hardware and should not need to change for Xmega. This is one of the clever things about FatFs - it isolates the h/w specific bits so porting to new targets is very easy (which is why it's available for all kinds of CPU and "drive" types).

I think I have a hardware issue... the program doesn't get receive anything from the card within disk_initialize>send_cmd. I'm trying to communicate with a micro SD via a SD adapter, I believe the pin-out is different. 9(SD) is 1(microSD) and pin 3(SD) is not connected to the microSD. I have an LED set up as shown in foolproof.jpg

Managed to finally write to the card!! the issue I have now is at power-up some times it works sometimes it doesn't.

It seems to have more success when I wait about 5 seconds before powering up again, however I wish for it to be able to power off and on within 0.5 seconds. I have 100nF caps from Vcc to ground that seem to be holding charge for a bit, Could this be why? I added a bleeding resistor hoping it would discharge faster, didn't really change much.

Is there something I can do to power down faster? I only have one capacitor between my regulator and the uC , I know it sounds bad but its a small scale design?

TWI comms work perfectly. It may be something to do with my clock settings or something as well I guess. I'm a little lost haha. I have probably been pretty vague as well, which doesn't help anyone.

Just to say (despite how it looks!) this thread isn't really the place to diagnose FatFs and/or SD/MMC usage problems. The plan should be that this is just here to develop the text of the first post. So if you have some issue to diagnose it might be better to start a new thread elsewhere.

FI have read through this forum (well, most of it) and pretty much all the documentation by elm-chan. I downloaded the latest sample project release oct. 14th 2017 which can be found here: http://elm-chan.org/fsw/ff/ffsample.zip There are a couple of new files in here that I am unfamiliar with and unsure of how to proceed.

It would be great to continue this thread documenting various avr platforms and newer revisions of FatFs.

Problem summary:

Every time I do a disk_initialize(0) I get a STA_NOINIT. I have probed my spi lines and I see nothing.

hardware:

I am using a mega2560 as my development avr. (uses the atmega2560) I am using the spi lines through a level shifter to connect to the SD card (microSD to SD adapter) my connections are as follows: