Recently, I've been thinking a lot about how STM32 communicates with an SD card. For a long time, I struggled with both the driver and the application of the SD card. During winter break, when I came across the simplified physical layer protocol of the SD card, I felt completely lost. Seeing the 3000 lines of code for the SD driver made me feel overwhelmed. However, after reviewing the relevant content on the SD card several times over the past few days, I’ve managed to gather some insights and now believe it’s not as complicated as I thought. I decided to break down the SD driver and its application into layers, which helps build a clear logic. As one computer master once said: "All computer problems can be solved by layering."
I have divided the SD card's functionality from the driver to the application into four layers, from bottom to top: the driver layer, the physical layer, the file system layer, and the application layer. Let's take a closer look at the key operations in each of these layers.
1) Driver LayerThe driver layer corresponds to the ST library, specifically the files stm32f10x_sdio.c and .h. When using any STM32 peripheral, you always rely on the corresponding .c and .h files. The SDIO peripheral is used to manipulate registers. Since this involves using the ST library functions, I can't explain them in detail here. The implementation process will not be discussed in depth.
2) Physical LayerThis layer can be considered the first level, connecting the driver layer and the file system layer. It manages files in a unified way and can be described as the core of the entire SD driver. If the requirements for the SD card are not high, you can directly perform file operations at this level, but it's very inconvenient without a file system. The reason it's called the physical layer is because this part of the code mainly refers to the "SD card physical layer simplified protocol." This protocol defines the format and timing of the commands that the controller sends to the SD card. This layer corresponds to the files sdio_sdcard.c and .h in the source code. What is its main function? The most important function is SD_Init(), the initialization function of the SD card. This function includes three key steps: power-on, identification, and card initialization, corresponding to two sub-functions: SD_PowerOn and SD_InitializeCards(). The return value of SD_InitializeCards() contains information about the type of card. These sub-functions are implemented by sending CMD commands through the STM32's built-in SDIO controller. Sending a CMD command requires strictly following the flowchart of the SD protocol and checking flags in time, otherwise the program may crash. To send a CMD command, you fill in the SDIO_CmdInitStructure structure, such as:
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 has five parameters, controlled from top to bottom: argument, command index, response format, wait, and hardware flow control. Filling out these five parameters configures the CMD command format, and then you use the SDIO_SendCommand() function to send it. In addition, this layer also includes the initialization of other peripherals—such as NVIC (interrupt vector priority configuration), GPIO (SD slot IO port setup), and DMA (data transfer via DMA mode). In summary, this part is where the host (STM32) controls the SD card using CMD commands. Therefore, at this level, you can directly call functions for initialization and read/write operations. But why do we need a file system layer?
3) File System LayerThe file system layer exists to manage files. An ordinary 8GB SD card, if operated directly through the physical layer, would require the user to remember many details like file addresses and lengths. These tasks were originally handled by computers, so people invented the file system. This system manages large-capacity storage devices, making operations more convenient. Without a file system, you’d have to manually input addresses like 0x20000f54, which is impractical. The file system acts as a management layer, connecting to the SD card’s physical layer, sending various CMD operations to the SDIO controller, and providing functions that developers can easily call. It is also the key code that makes everything work. Fortunately, someone has already written most of this code for you. You just need to make minor adjustments to create your own file system. FATFS is a great example of this—it is highly versatile, completely independent of the driver layer, and provides some interface functions. Migrating it to different platforms is straightforward by filling in the corresponding interfaces. This interface connects the SD card’s physical layer with the file system operations. The ff.c and .h files in this layer are written by a distant developer, so I won’t go into details here.
4) Application LayerThis layer is typically handled by hardware developers. Since the platform varies, the interface functions at this level are completely different. The application layer consists of various interfaces left by the upper layer (file system layer). You fill in the interface functions and then directly run the file system. How do you write these interface functions? In addition to the function name, FATFS also specifies the parameters and the corresponding functions for those parameters. The help file shows what needs to be implemented by the interface function. In fact, you can often guess what the function does based on its name. For example, disk_read means reading the disk. To implement the disk read function, this interface must call functions written in the physical layer, such as SD_ReadBlock(). As long as the child function and parent function call parameters match, the consistency between them requires the developer to fully understand the function and its parameters. This part of the code is small and not difficult to write, but it's crucial to pay attention to the flag states.
At this point, the SD operation functions have been encapsulated, and you only need to call the functions provided by FATFS. There are still many issues with the SD driver that I haven’t fully resolved yet. I just stepped through the source code and examined the implementation process. Now, I’m ready to try migrating the file system. I hope it works. The SD driver is still very interesting to work on. By connecting it with other peripherals, such as an MP3 module or an LCD display, you can achieve things like playing songs or displaying images, which gives a great sense of accomplishment. Before, I used electronic products without realizing how complex it was to listen to music. From the original binary code 0101 to the analog signals we see and hear, after so many processes, I just had to admire the endless wisdom of human beings.
Power Adapter,Universal Power Adapter,Usb Power Adapter,67W Usb-C Power Adapter
Guang Er Zhong(Zhaoqing)Electronics Co., Ltd , https://www.geztransformer.com