The purpose of this KBA is to make an initial, low level function library (hereinafter: SDIO driver) for the SDIO peripheral of the EFM32GG11B Giant Gecko STK and then a short example code will demonstrate its operation. Furthermore, this KBA's primary role is to give a good base for further development and it can perform easy operations between memory card and the MCU. Low "level function" means that the SDIO Driver uses just the MCU and the SDIO peripheral related registers and the implemented example will not use higher level software, e.g.: FAT handler software package. Initial means that the implementation from SD Host Controller Simplified Specification Ver3.00 (hereinafter: Host Spec) and from the Physical Layer Simplified Specification Ver 6.00 (hereinafter: Card Spec) is not holistic. In other words, the necessary relevant parts of the previously mentioned specifications are implemented. The further sections will describe these parts.
Figure 1 - High Level description
Figure 1 gives a high-level schematic about the used things (HW and SW) and newly implemented codes. The previously available things are marked with grey color and what this KBA implements are marked with green and orange color.
The whole example section is realized in the 'main.c' file. This example will perform basic, low level operations between the MCU and the memory card. Basic means that for addressing the memory card, the example code will use direct SD card section's address to perform the write and read operations (no FAT table).
The reader will get an initial, low level driver for the SDIO host and for the memory card with the following features:
Base information for the proper understanding and for further development is that the EFM32GG11B related SDIO peripheral and the SDIO host peripheral (which is described in the Host Spec) are the same peripheral. Therefore, you can use Host Spec documentation for using the SDIO peripherals. It is good news for developers because the efm32gg11b reference manual's section about the SDIO peripheral is just 60 pages, but Host spec is much more, nearly 160 pages. Both specifications (Host Spec and Card Spec) give a very good and easily understandable description about the operation of the SDIO and the memory card. Therefore, the primary role of this chapter is not copy paste sections from the specifications. Instead of that, it will give a passage between the implemented SDIO driver and the used specifications.
The SD card driver is mostly the memory card command related items in the source code (e.g.: CMD24 macro). The SDIO host driver related items are mostly the 'Sequences' which are defined in the Host Spec on page 92. The border between SDIO host and SD card drivers is melted because both document describe the same sequences, but the descriptions are based on different point of view.
The SDIO driver has 2 types of functions:
This kind of classification helps for developers/users which functions are necessary for using of SDIO Driver and which ones contribute for the inner operation of the SDIO Driver. In case of using, the user can see which functions are developed in order to using (public functions) and which functions performs inner operation (private functions, these functions are not directly usable functions). In case of development, the developer can see which functions inner functions are and they can easily modify/delete/create these kinds of functions.
The private functions cannot be called from outside of the SDIO driver. These functions contribute to the simplicity of the module, perform inner mechanism which based on the state of the SDIO/SD registers, etc. Naming convention of these functions is: SDIO_S_comprehensive_name. The public functions can be called from outside of the SDIO driver. These functions realize main desired functionalities. Naming convention of these functions is: SDIO_comprehensive_name. Generally, these functions call and schedule the driver related private functions. The following functions are public functions
SDIO_GetActCardStateType()- (this function will not be used in this example)
The following mapping table (Table 1) will help to establish the connection between the functions of the SDIO driver and the Host/Card Specs.
Table 1 - Mapping Table
The goal of this function is to initialize the MCU related SDIO peripheral, initialize the SD card and at the end modify the state of the SD card from standby to transfer mode. In transfer mode the SD card can write and read its sections.
The function will initiate a single read or write operation between the SD card and the MCU. Both functions have 3 parameters:
Independently of the direction of the operation, the amount of the data will be 512 bytes which is implemented in the SDIO_Init() function. For the read/write operation the MCU will use its CPU - no DMA support, but it also can be implemented in the SDIO_Init() function.
At the end of the execution the reserved ram area of the MCU will be filled with the content of the selected memory card's data and the memory card's selected pages will be filled with the content of reserved memory's content. (in the case of example with 'F').
i am using EFM32GG11B820F2048GQ100 , but above code example not working in my controller
Do you use EFM32GG11B STK - BRD2204A Rev BD4 board?
Thanks @Tibor Bakos
No i am using custom board along with part number EFM32GG11B820F2048GQ100
and sandisk memory card (SDHC) ,Class -4 , 16 GB
Do you get compiling errors, or you can upload the FW and the problem relates to the execution?
No, i am not getting any compile errors
i can upload firmware to board successfully but nothing is written to sd card
If you start the execution on debug mode (basically, start with F11), does the FW code execution reach the while (true) cyclic? If not, where is it stop?
Actually after debugging i found that program is stuck at below point
while (!(sdio_t->IFCR & _SDIO_IFCR_CMDCOM_MASK));
in SDIO_S_SendCMDWithOutDAT function
it doesn't reach to while(true) loop
I have more ideas what can cause this problem.
1. I've taken a fast look to the EFM32GG11B820F2048GQ100 pin out's and it looks like it also has pins what GiantGecke devboard has (the used ones for the project). PE7 pin in BSP_SLSTK3701A_SDIO_HWInit() function is devboard specific pin (power enable pin to SD), but all other Pins should be routed between your SD card reader and your MCU (recommended).
2. After checking, you should debug the SDIO_S_CardInitialization_and_Identification() function. This function performs the low level initialization of the memory card. (e.g.: volateg level). In this state, the SD card uses only a few pins (CLK,CMD,WP,CD as I remember) and every memeory card should have same behaviour. Thats mean that if you start debugging in this level, stating with :
// 1. Reset Card
SDIO_S_SendCMDWithOutDAT(sdio_t, CMD0, 0);
and problem appears in this section, that'll mean this problem's root relates to HW issue (or improper initialization of the HW prepiherals, eg GPIO). Or other, but firstly, we should check it.
Can you debug the SDIO_S_CardInitialization_and_Identification() function? What is your experiance with it?
i have tested but program again stuck at same place which i have mentioned before in
SDIO_S_CardInitialization_and_Identification() function , problem is related to hardware , so let me clear one thing
I am using custom board for testing , so i have changed some pins from original which is given in code like
so i have paste here my BSP_SLSTK3701A_SDIO_HWInit function here
// Soldered sdCard slot
GPIO_PinModeSet(gpioPortE, 7u, gpioModePushPull, 1);
GPIO_PinModeSet(gpioPortA, 6, gpioModeInput, 0); // SDIO_CD
GPIO_PinModeSet(gpioPortE, 15, gpioModePushPullAlternate, 0); // SDIO_CMD
GPIO_PinModeSet(gpioPortE, 14, gpioModePushPullAlternate, 1); // SDIO_CLK
GPIO_PinModeSet(gpioPortA, 0, gpioModePushPullAlternate, 1); // SDIO_DAT0
GPIO_PinModeSet(gpioPortA, 1, gpioModePushPullAlternate, 1); // SDIO_DAT1
GPIO_PinModeSet(gpioPortA, 2, gpioModePushPullAlternate, 1); // SDIO_DAT2
GPIO_PinModeSet(gpioPortA, 3, gpioModePushPullAlternate, 1); // SDIO_DAT3
// GPIO_PinModeSet(gpioPortB, 9, gpioModePushPullAlternate, 0); // WP
i have not used WP pin in it
for your detail clarification i have atttached my board schematic here
Thanks, it was a helpful update. As I see, you've modified the SDIO_CD pin location. Did you modified the PIN related ROUTELOC0 register according to the pin modification? (you can find it at the beginning SDIO_S_LowLevelRegisterInit() )