CE SD Card Driver Development (Zylonite) (RPM)

2008-06-05 09:45

1. SD card Drive architecture under WINCE Wince SD Card Driver protocol stack consists of: host hardware bottom part (main control side drive) sdhc_xxx. DLL Bus Intermediate Logical command layer (bus driver) Sdbus. The DLL client upper layer (client drive) sdmemory. Dll The main control side drive main control side drive control contains the main controller hardware, follow the main control side drive interface, it is used for bus-driven communication and set operating parameters. The host Controller driver interface provides a hardware extraction layer between the bus and the main control side. namely: Sdhc_xxx. DLL is the lowest level, because this layer is the hardware association layer, so named XXX is to correspond to the specific hardware BSP package (such as the hardware platform of this project is Zylonite, its hardware supplier to the BSP package name is Zylonite, in the actual project we will sdhc_xxx. The DLL is replaced by Sdhc_zylonite. DLL), which is responsible for specific commands and needs to be modified in most cases. Bus-driven Bus drivers act as the extraction and management layer between the master control driver and the client driver. It is included in the SDbus.dll file. Provides a standard API for client-side drivers that allows running on any Windows CE-based device. The bus driver will be independent of the application and the main control side drive, porting between different processors, without the need for changes. SDBus.dll is the middle tier, responsible for consolidating commands and management. Client-driven client-drive and SD client-drive communication interfaces allow client-side drivers to communicate with SD devices. The client drive interface is a planned abstraction of the execution of the SD bus physical device, providing the client-driven maximum elasticity. The client driver interface allows the client driver to measure a single, synchronous access memory card driver using a thread that is driven by an asynchronous communication device. SDMemory.dll is the highest layer, similar to the application layer. 2. Based on the Microsoft SD Card protocol stack Development Zylonite BSP package SD card Driver When we developed the SD card driver, and detailed analysis compared to the Microsoft SD Drive architecture and Intel provided by the BSP SD card driver, we can draw the following conclusions: For the main control side drive (sdhc_xxx. DLL): Because this layer is a layer of direct manipulation of the hardware, it needs to be modified in most cases. The modified content is basically the send and Receive commands section as well as the data transfer and hardware initialization sections. For bus drivers (SDBUS.DLL): Because this layer is between the main control driver and the client driver for communication between them, the SD card bus request is placed in it, Microsoft provides a very complete sample code, so we generally do not need to change, directly call its interface on it. For client-side drivers (sdmemory. DLL): Because Sdmemory is called the client layer, similar to the application layer, it can also be used to identify cards, different types of cards, such as SD memory card, etc., since we only need to develop the SD card part of the driver, So there is no need to modify the (if I want to develop SD interface of the SDIO device, then you have to make a relatively large change in this layer). Intel provides the BSP reference SD card driver to implement the main control side drive (Sdhc_zylonite. DLL) While the bus driver (SDBUS.DLL) and the client driver (sdmemory) are called and retained. DLL). Therefore, combined with the specific hardware design (SD card connector, etc.), our main task is to utilize the SD card Master driver code in BSP, develop (configure and improve) The SD card driver in our actual project. Overview of the main control side of SD card in Zylonite BSP The driver for the SD card is provided in the form of a stream, and the SD card main control side driver is provided in Sdhc_zylonite.dll form, the entry is in:/WINCE500/PLATFORM/ZYLONITE/PUBLIC/CSP/MONAHANS/SDHC There are two files as follows: SDCONTROL.C: Contains a very important thread---sdcontrolleristhandler, mainly responsible for the card and controller interaction, processing controller received messages, such as the specific control and processing functions in this file. The export stream interface of the MAIN.C:SDH (main control side driver) is implemented in this file and contains the entry point of the main control side driver (Sdhc_zylonite.dll). The SD card hardware initialization and its main control side drive registry information setting path is:/WINCE500/PLATFORM/ZYLONITE/PLATFORM/ZYLONITE/SRC/DRIVERS/SDHC The main documents are: IMPL.C: The primary is to initialize the hardware when the SD card is loaded on the main control side of the driver. Contains a non- Often important threads----sdcarddetectistthread, specifically handling SD card plug-and-unplug operations. However, the specific plug-and-unplug operation is also implemented in the Sdcontrol.c file. External pin and function configuration of SD card In the actual project (a gsm/phs dual-mode smartphone with wince as the operating system core), the external pin of the SD card and the monahans_l's Gpio connection diagram and the circuit diagram of the connection controller are as follows: The external pins and functions of the SD card must be configured first. The pin configuration of the SD card is modified within the XLLP_MMC_BOARD.C file Xllpmmcconfigure function of the/source folder under it. (Special note: The GPIO34 is to be paired with an interrupt source for detecting SD card insertion.) ） Analyze modification and improve the main control side drive important threads and hardware initialization part of the code Driver loading and architecture analysis of SD card main control side It is necessary to declare that the SD card driver loading sequence is: Load sdbus.dll→ load sdhc_zylonite.dll→ load Sdmemory.dll We are here to discuss only the 2nd step (Sdhc_zylonite.dll loading), at which point the SDBus.dll has been loaded successfully. After the wince system is initialized, the DEVICE.EXE is loaded and the corresponding code devload. The WinMain function in C is called to start the Initdevice function, which searches for the function (/wince500/platform/zylonite/platform/zylonite/src/drivers/ Sdhc_zylonite.reg) Registry root key, prepare parameters call WIN32 API Interface-----Activedevice, and then use DllMainCRTStartup function to find sdhc_ Zylonite.dll the entry, execute the entry function of the file DllMain () and then continue to return to DEVICE.EXE (DEVLOAD.C), call the Launchdevice () function, and then call SDHC_ The Zylonite.dll entry in the Main.c file is Sdh_init (), since this will begin the initialization process that will start the main control side of the SD card driver: 1. Call Sdh_init () 2. Call Sdhcdallocatecontext () to allocate a part of the host controller's context a) context is 3 of the bus drive and the main control side drive share. The main control side driver uses the SDHCDSETXXX macro to populate the context structure a) This step is to describe the main controller to the bus driver B) including function pointers, supported currents, maximum clocks, number of slots, SDIO support, etc. 4. Call Sdhcdregisterhostcontroller () to register yourself with the bus driver 5. When the bus driver is ready to handle the SD event, it invokes the main control-side-driven init function (Pcontext->pinithandler) Next is the Sdbus.dll driver part of the code and the SD card main control side of the driver part of the interactive settings: such as setting the power supply, clock and bus width. Generally, the Sdbus.dll initiates the request and then calls the API of the main control side driver section, where the slot state interaction confirmation is analyzed in detail, as this is the key to successfully loading the sdhc_zylonite.dll. When there is an SD card in the slot, Sdbus.dll Slotstatuschange () calls and establishes an important thread sdcarddetectistthread (), when the detected card is returned to Sdbus.dll, The Handleadddevice () function is called by the bus driver, and the Sdhc_zylonite.dll load succeeds since this initialization is complete. Improvements to key thread Sdcarddetectistthread () code for main control side drivers In the previous narrative, you can see that thread sdcarddetectistthread () plays a decisive role in the final loading of sdhc_zylonite.dll. However, we found that in the BSP given by Intel, in the process of detecting the card, it uses the polling method----that is, every time, the CPU will read the GPIO34 level, to determine whether the SD card is inserted or unplugged, This is to determine whether to load or unload the SD card client and the main control side driver. Obviously, the disadvantage of this approach is that it takes up too much CPU resources and is inefficient, which seriously affects the real-time of the whole system. Therefore, the best way to solve this problem is to use the method of interruption detection. Interrupt binding static Configuration: 1. Define a system interrupt number within the Bsp_cfg.h file Sysintr_sdmmc_detect #define Sysintr_sdmmc_detect (Sysintr_firmware+n) N is the maximum value currently defined (to ensure that this interrupt has not been used). 2. Find the definition of GPIO34 in the Xllp_gpio_plat.h file: #define XLLP_GPIO_MMC_CD_0 34 3. Associate the system interrupt number and IRQ in the Intr.c file: Oalintrstatictranslate (Sysintr_sdmmc_detect, Irq_gpio_share (XLLP_GPIO_MMC_CD_0)); 4. Add the Enablesdcardinterrupt () function to Initializehardware () in the hardware initialization code IMPL.C driven by the main control side. 5. Refine Enablesdcardinterrupt () in impl.c to add detection and set EVENT for Gpio rising or falling edge. 6. Define hcardinsertinterruptevent in the Impl.c file and create hcardinsertinterruptevent within setupcarddetectist () The 7.impl.c file initializes the dwsysintrcd= Sysintr_sdmmc_detect and binds the corresponding event:interruptinitialize (DWSYSINTRCD, hcardinsertinterruptevent,null,0) 8. Improve the while part code of Thread Sdcarddetectistthread (), add WaitForSingleObject (Hcardinsertinterruptevent, dwtimeout); It is only when hcardinsertinterruptevent is placed that it will go down or wait here. 9. The same principle rewriting cardremoveinterrupt is used to dynamically unload the SD card main control side drive.

CE SD Card Driver Development (Zylonite) (RPM)