Some thoughts and conclusions on the communication between STM32 and SD card

SD drivers and applications have troubled me for a long time. I was stunned when I saw the simplified version of the SD physical layer protocol during the winter vacation. I was also shaken when I saw the SD driver's nearly 3,000 lines of code. In the past few days, I have read the relevant content of SD cards and summarized some experiences. I don't think it's so scary anymore. I decided to discuss SD drivers and applications from a layered perspective, because this can build a clear logic, and I don't know which computer master once said: All computer problems can be solved by a layered approach.

I divide the SD card from driver to application into 4 layers, from bottom to top: driver layer, physical layer, file system layer, application layer. The following introduces some important operations of each layer one by one.

1) Driver layer

The driver layer corresponds to the ST library, which is the two files stm32f10x_sdio.c/.h. In fact, any STM32 peripheral cannot be separated from this pair of corresponding .c/.h files as long as the library function is used. For the SDIO peripheral, it is used to operate the register. Since it involves the writing of ST library functions, I am not able to understand it, so I will not go into details about its implementation process.

2) Physical layer

This layer can be said to be a link between the upper and lower layers. It is connected to the driver layer below, which is used to operate registers, and the file system layer above, which is used to uniformly manage files. It can be said to be the core code of the entire SD driver. In fact, if the requirements for SD are not high, you can directly perform file operations on this layer, but it is really inconvenient to operate without a file system. The reason why it is called the physical layer is that the code in this part mainly refers to something like "SD card physical layer simplified protocol". This protocol specifies the format and operation timing of various instructions for the controller to operate the SD card. This layer corresponds to the two files sdio_sdcard.c/.h in the source code, so what functions does it mainly implement? The most important function in this layer is SD_Init() - the initialization function of the SD card. This function includes the three important steps of SD card power-on, identification, and card initialization, which correspond to two sub-functions - SD_PowerOn and SD_InitializeCards(), and the return value of SD_InitializeCards() contains the card type information. The implementation of these two sub-functions is to send the CMD command through the built-in SDIO controller of STM32. The sending of this command must strictly comply with the flowchart of the SD protocol, and the flag bit judgment must be performed in time, otherwise the program will easily run away. Sending the CMD command is completed by filling in the SDIO_CmdInitStructure structure. For example:

SDIO_CmdInitStructure.SDIO_Argument = 0x00;

SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_APP_CMD;  
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;

This structure contains five parameters, which control from top to bottom: parameters, command index, response format, whether to wait, and hardware flow control. Filling in the five structures also configures a CMD command format, and the command can be sent using the SDIO_SendCommand() function. Of course, this layer also includes the initialization of some other peripherals - NVIC (configure interrupt vector priority), GPIO (configure the IO port of the SD slot), and DMA (transfer using DMA mode). To sum up, this part is that the host (STM32) controls the SD card with the CMD command, so at this layer, you can directly call the function to perform initialization, read and write operations. So why is there a file system layer?

3) File system layer

Its existence is used to manage files. An SD card, nowadays, is usually 8G. If it is operated directly using the physical layer, the operator has to remember the addresses, lengths, etc. of many files. These things can be done by computers. Therefore, people invented a file system to manage large-capacity storage devices. If it is operated on the file system, the whole pattern will appear larger and more high-end. Otherwise, you have to write an address to call a file, such as 0x20000f54, which will drive people crazy. Having said so much, the role of the file system is a management layer, which is connected to the physical layer of SD and is used to send various CMDs to operate the registers of the SDIO controller. It is also the key code that connects the upper and lower layers. And fortunately, someone has already written most of this code for you. You only need to make appropriate modifications to use it for you and build a file system. FATFS is something that a kind person in a very distant place has already written for you. This thing is very versatile and completely separated from the driver layer. It leaves some interface functions. You can fill in the corresponding interface functions on which platform you want to transplant it. This interface connects the physical layer of the SD card and the operation functions of the file system. The ff.c/.h files corresponding to this layer are also written by a great god far away, so I can't understand them. So I won't talk about how to implement them here.

4) Application layer

This layer should be the one that hardware developers can use, because the corresponding platforms are different, and the interface functions of this layer are completely different. The application layer is composed of various interfaces left by the upper layer (file system layer). After we fill in the interface functions, we can run the file system directly. How to write interface functions? When leaving the interface, FATFS not only leaves the function name, but also leaves the parameters and the corresponding functions and formats of the parameters. The help file contains the functions to be implemented by the corresponding interface functions. In fact, you can guess them by the name of the interface function without checking the help file, such as disk_read, which is to read the disk. To implement the disk reading function, this interface function must call various functions written in the physical layer, such as SD_ReadBlock(). Just pay attention to the consistency of the calling parameters of the child function and the parent function. This consistency requires developers to fully understand the function of the function parameters. This part of the code is very small, and it is not difficult to write. You just need to remember to judge the flag bit.

At this point, the SD operation function has been encapsulated, and you only need to query the functions of various operation functions in FATFS to call it.

There are still many issues that I haven't figured out about the SD driver. I just debugged the source code step by step and looked at the function implementation process. Next, I will try to transplant the file system. I hope it will be successful. It is still very interesting to make the SD driver. By connecting it with other peripherals, such as MP3 modules or LCD screen modules, it can play songs and display pictures. It is quite a sense of accomplishment. When I used electronic products before, I didn't expect that listening to a song or watching a picture would be so complicated. From the original encoding of 0101 to the analog signal we see and hear, it has gone through so many processes. Thinking about it, I can only sigh at the endless wisdom of human beings.