STM32 and SD card communication layer analysis

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 SD cards. During winter break, when I came across the simplified physical layer protocol of the SD card, I felt quite confused. I saw that the SD driver had over 3000 lines of code, which made me feel overwhelmed. In the past few days, I revisited the relevant content about SD cards, summarized some experiences, and now I feel it's not as complicated as I thought. I decided to break down the SD driver and its application into layers, as this approach helps build a clear logic. I remember a computer master once said: "All computer problems can be solved in a layered way."

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 what each layer does.

The 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 it involves writing ST library functions, it's hard to fully explain without diving into the code. The implementation process won't be detailed here.

This layer is the first one, connecting to the driver layer and managing the file system. It can be considered the core of the entire SD driver. If your requirements for the SD card are simple, you can directly operate files on this layer, but it's really inconvenient without a file system. The reason it's called the physical layer is because it follows the "SD card physical layer simplification protocol." This protocol defines the format and timing of the commands sent by the controller to the SD card. This layer corresponds to the sdio_sdcard.c and .h files in the source code. Its main function is SD_Init(), which includes three key steps: power-on, identification, and card initialization. These are handled by sub-functions like SD_PowerOn and SD_InitializeCards(). The return value from SD_InitializeCards() contains the card type information. These sub-functions are implemented by sending CMD commands through the STM32’s built-in SDIO controller. The command flow must strictly follow the SD protocol, and flags should be checked in time to avoid program errors. Sending a CMD command involves filling 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 has five parameters: argument, command index, response format, wait, and CPSM. Filling out these parameters configures the CMD command format, and then you use the SDIO_SendCommand() function to send the command. This layer also initializes other peripherals like NVIC (interrupt vector priority), GPIO (SD slot configuration), and DMA (DMA transfer mode). In short, this layer allows the host (STM32) to control the SD card via CMD commands, enabling direct initialization and read/write operations. But why do we need a file system layer?

The file system layer is designed to manage files. An 8GB SD card, if operated directly through the physical layer, would require the user to remember many file addresses and lengths—something that’s impractical. That’s why file systems were created. They manage large storage devices, allowing users to interact with files rather than raw memory addresses. FATFS is a widely used file system that provides a generic interface, making it easy to port to different platforms. It abstracts the physical layer, offering a set of functions that developers can use. The code in ff.c and .h is written by someone far away, and I don’t fully understand it here.

This layer is where hardware developers come into play. The interface functions vary depending on the platform. The application layer uses the interfaces provided by the file system layer. You fill in those functions and then call the file system directly. To implement these functions, you need to refer to the FATFS documentation, which outlines what needs to be done. For example, disk_read is a function that reads from the disk. To implement it, you might call lower-level functions like SD_ReadBlock(). Consistency between child and parent functions is crucial, and this requires a deep understanding of the parameters involved. This part of the code is small and not too difficult to write, but attention to detail is important.

At this point, the SD operation functions are encapsulated, and you just 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’ve only stepped through the source code and looked at the implementation. Now I’m preparing to try porting the file system. I hope it works. Working on the SD driver is still very interesting. With additional peripherals like an MP3 module or an LCD, you can achieve things like playing music or displaying images, which gives a great sense of accomplishment. I used to think that listening to songs was simple, but after seeing how all the processes work—from binary code to analog signals—I couldn’t help but admire human ingenuity. It’s truly endless.

EI 66 Transformer

Ei 66 Transformer,Transformer Ei 66 X 36,Ei66 50V Audio Transformer,Ei66 30W 8Ohm Audio Transformer,240v to 12v transformer

Guang Er Zhong(Zhaoqing)Electronics Co., Ltd , https://www.geztransformer.com