As well as the actual interface signals to the SD/MMC card most sockets also have two physical sensors (switches) called "Card Detect" (CD) and "Write Protect" (WP). It is the CD signal - that they bring out as SD_CD that your AVR code needs to read to know if there is a card present r not. Looking at the schematic it is pulled up using a 10K. So it's presumably active low. So the AVR code should be looking for that signal being "0" to determine that there is a card in the slot.

In FatFs there is a timer interrupt that senses the state of WP and CD every 10ms. If it ever "sees" CD go non-active it knows that the card has been removed and possibly replaced and that there is a likely need for it to be reinitialised.

I don't know the ASF code but I rather suspect it will be doing something very similar. I would dig down into the code of sd_mmc_check() in ASf and find out what it's actually expecting.

(this for mega not xmega) to tell it where to look for CD and WP signals. Again an assumption but I guess ASF must have some kind of config where you tell it where to look for WP and CD?

PS can I just say that I hate the way ASF is held as a Git repo. To explore this I would have to create a project that checks out the files involved here - I just want some way I can browse the ASF sources without having to create a project (and know which modules to pick to include)! If I could access it I'd have a look at what that check() function does and also how it might be that you tell it which IO the WP and CD signals are on.

With adjusting the code on low lvl. This way the higher functions still work

For so far i tested i can create a file on the SD card and probably write and read the file.

But i'm currently testing it. So don't know for sure.

PS:

I know the ASF is annoying to work with, but there isn't anything better that help you work with the xmega series. In the PDF's isn't a clear register table and if you open an example project you could kind off figure it out yourself.

Including "FatFs"? I know the code presented in FatFs for AVR is for a mega (or tiny in the "foolproof" case) not xmega. But as the only hardware it touches are (a) the SPI, (b) a couple of IO and (c) a timer then I would have thought it would be pretty easy to port it to Xmega (assuming someone hasn't already). You will get much better support if you use FatFs as that's what probably 95% of AVR users who have connected SD/MMC are using (me included).

That's exactly what i did. The code i ported also uses FATfs for a atmega. So i ported it to xmega by only changing the SPI, I/O's and some other little stuff. That wasn't so hard as you say.

But, i first tried to do that with the xmega example to let it work over spi. The xmega has een example for using FATfs, but uses it to read and write a memory block on the xplained bord trough usart-spi poort.

I tried to change it to the poorts of SPI for my SD card, but it wouldn't work. Because it didn't find the SD card or something.

So, it is easier to poort a working code on the atmega with spi to an xmega, then change code from an xmega example code to my preference.

Another reason why the ASF is annoying to use.

(also using a function that is in another file, that uses another function in another file and so on... That is something i personally hate, but yea the functionalities are wide of the xmega so i will bear with it )

Why, exactly how many SD/MMC sockets have you got attached to your Xmega? Do you really have two or more and therefore need to differentiate them as "device 0" and "device 1"?!? Otherwise you just always use "0" as you (like 99.8% of the rest of us) only have one socket.

But the xplained board had a memory block mounted on it (AT45DBX). The example program uses that memory block to read and write data with FATfs.

That works fine, but i want to change it to only read my SD card (which is connected to SPIC poort). But i cannot find where they choose the device. I don't think that the device number has anything to do with it.

To handle multiple drives (and especially drives of different types such as AT45 and SD) you need special implementation of the disk_*() functions. Note how disk_initialize(), disk_read(), disk_write() and so on are each passed a "physical drive number". So you would need implementations of those that did something such as:

As it stands I guess the supplied code has a single disk_initialiize() (and others) that basically ignores the BYTE parameter and just operates on the AT45 - they would all need to be "moved down a level" and then a wrapper such as the above introduced to respond to the single call to disk_initialize() from ff.c. You'd also need to bring the routines from mmc_avr.c into the mix - suitably renamed with something like that _sdmmc() suffix I show above.

You would now choose "0:" for the AT45 and "1:" for the SD/MMC

Before you go to all this complication ask yourself - do you really need BOTH types of storage? If you have GB's of storage in SD/MMC then what is the actual point of a Megabyte or two in AT45?

In whatever FatFs code you have there will be one file implementing the disk_*() functions. Just replace that with the mmc_avr.c from a recent FatFs and you should be good to go. The only job then is to edit the few lines of that file that interact with the GPIO and SPI and change them to Xmega equivalents.