Shortly: choosing one of the available Silicon labs FatFS projects (SD example code - \sdks\gecko_sdk_suite\v2.4\app\mcu_example\EFM32GG_DK3750\fatcon) which uses SPI-driver based memory card handling. Then modify this project according to this chosen project's objectives to be able to run on a SLSTK3701A board with the SDIO Initial Driver.
This KBA will give a general description about the relation between FatFS, SDIO/SPI SD card driving and the chosen FatFS SD example code. At the end of the article the reader will get a FatFS project which will be able to run on the EFM32GG11B STK - BRD2204A with the SDIO driver instead of SPI driver. In the Silicon Labs software collection there are several FatFS example projects but all of them using SPI based SD card driving. This documentation also will describe the process of the modification, so based on this article the user can use this process to adapt the already available SPI based FatFS projects to SDIO driven FatFS project.
The structure of this KBA can be divided to 2 parts:
This chapter will describe the process how the original, SPI based FatFS example project has been modified. The steps are logically divided to 3 parts: input, which describes the available sources; output, where the summarized expected output has been described and the function, where the essential modifications are summarized in order to reach the expected outputs.
Firstly, we have to examine the operation of the available FatFS project (with SPI driver) and then have to plan what we should modify in order for the FatFS example to work on another board with different SD card driving peripheral (from SPI to SDIO).
The following table will classify the project related software and hardware components based on the task what these packs are doing. As synonym of the pack, I will use the word: layer. A minor description about these layers can be found in the following sections.
Table 1 - Comparison of the SPI and SDIO based projects
Figure 1 - Comparison of the SPI and SDIO based projects
This chapter will give description for the previous chapter mentioned layer modification and about the modification of the layers.
For the sake of simplicity, the introduction of the layers will start from application. The SPI driven project’s application and the SDIO driven project's application should be the same. At the end, there will be a little difference between the original application's provided functionality and the modified example project functionality because the SDIO driver has reduced capability. SDIO has been made to perform data write / read operations between the MCU and memory card, and the SPI based project has functionality which reads the memory card related size out from the memory card's register. After a deep examination, it was recognized that that the structure of the SDIO driver should be modified in order to perform this memory card size related read operation. It was decided that the driver would not be structurally modified, so the memory card size related functionality is not supported. It is not scope of this KBA.
During this modification, the upper layers of the FatFS will not be modified. I do not have to examine the whole FatFS so I just separate a "logical layer" from the FatFS and I modified it. The separated layer will be called as: "FatFS – (SPI/SDIO) Card link layer". This layer related files are: diskio.c and diskio.h.
This layer is responsible for:
The related files were diskio.c and diskio.h. The diskio.c file has been modified. Based on the SDIO Initial Driver is not a general peripheral driver, the FatFS SD Card link layer also is not a general layer. It just works with SDHC or SDXC cards. That means that if somebody wants to use an older card (MMC or the card size smaller than 2GB it will not working). The characteristics are similar with the SDIO Initial driver's characteristics.
This layer has 4 functions which has been modified:
The disk_initialize(),disk_status(), disk_read() has been modified regarding to SDIO driver related SDIO_Init/read/write functionality. The disk_status() is just software attribute, so it was not necessary to have it modified. The disk_ioctl() functionality has been modified according to the inner functionality has been stubbed, and the return values have been modified to a constant value. This modification does not have effect to the read, write operation. The reason why this trick has been used is that the scope of this description is not an entire driver, just a working example (with reduced functionality). The concept about how somebody can implement this feature will be described at the end of this KBA (see: Issue with CMD7 chapter).
The whole SPI driver has been deleted from the project and the SDIO Driver has been replaced to its place.
It has been modified from EFM32GG to EFM32GG11B. Based on the standardized library, the porting has been performed without any problem.
Firstly, download the attached .zip file and extract it. The extraction will produce a Simplicity Studio project. Then, you should import the previously extracted project to your Simplicity Studio. Build the project and then upload the built *.hex file to your EFM32GG11B STK - BRD2204A Rev BD4 board. Insert a suitable (SDHC card) memory card into the board related microSD socket. Then start a terminal emulator program (PuTTy, TeraTerm, etc). For demonstrating I will use TeraTerm.
Firstly, just choose the desired port. (you can check it in the Windows related Device Manager/Ports section)
Figure - TeraTerm Choosing
Then adjust the serial connection's parameters (baud-rate: 9600; 8-N-1; no flow control)
Figure - TeraTerm Adjusting
After pressing the OK button, you should see, a blank, empty window, with one cursor. Presuming that the following steps have been performed already: the SD card is inserted and the compiled *.hex file is uploaded to MCU. You should press the reset button of the board. This reset will initiate the initialization process of the SD card, and the first message from the board should arrive.
Figure - TeraTerm Initialization complete
Then you should use the SW as described in the TeraTerm window. Note: if the "ls" command does not work firstly, you should start with "umount", "mount" then "mkdir" commands.
The initialization and operation of the SD card is realized as highlighted on the above figure.
The green rectangles and arrows highlight the actual operation of the driver. The SD card initialization go through the “card identification mode”, then “stand-by state” and at the end to the “transfer state” (that what’s been implemented in the SDIO_Init function). Then the card state can go to “sending data” or “receiving data” state, after this, when the card finished its operation it will go back to “transfer state” again. That’s what exactly the SDIO Initial driver do:
The red arrow marks what state change should be implemented in order to SDIO driver be able to perform read its data (size, number of blocks, etc.). This information is available when the card in “stand-by state” and that’s why SDIO_Initial driver modification is necessary to read these data.