LPC55S6x单SDMMC控制器驱动双SD卡：SDK补丁与串行访问实践

1. 项目概述与核心价值

在嵌入式项目开发中，存储扩展是一个永恒的话题。无论是数据采集、日志记录、固件升级还是多媒体内容存储，SD卡因其高容量、低成本和高便携性，成为了许多工程师的首选。然而，对于像NXP LPC55S6x这类资源紧凑但性能强劲的Cortex-M33内核微控制器，其片上通常只集成一个SDMMC（Secure Digital MultiMediaCard）控制器外设。当项目需求从单卡存储升级为双卡热备、数据镜像或简单的容量叠加时，我们是否必须更换硬件或使用额外的外部控制器芯片？

答案是否定的。LPC55S6x系列MCU的SDMMC控制器在设计上就颇具前瞻性，它虽然是一个物理外设，但内部逻辑支持管理两套独立的引脚组，分别对应SD0和SD1。这意味着，从硬件角度看，它天生就具备连接两块SD卡的潜力。但翻阅官方SDK（Software Development Kit），你会发现其驱动和中间件默认只提供了对SD0（通常对应开发板上的那个卡槽）的完整支持。SD1的相关引脚虽然引出了，但软件栈是缺失的。

这正是本文要解决的核心问题：如何在不修改SDK核心源码、保持良好兼容性的前提下，通过“打补丁”的方式，为LPC55S6x的SDK补全对第二张SD卡（SD1）的完整驱动支持，并实现可靠的双卡访问。这个过程不仅是一次具体的功能实现，更是一次对SDK架构、硬件抽象层（HAL）和中间件设计的深度剖析。对于从事嵌入式存储、设备固件开发，或任何需要在单控制器上管理多路同类外设的工程师来说，其中涉及的“资源共享与分时复用”思想具有普遍的参考价值。

2. 硬件基础与设计思路拆解

在动手写代码之前，我们必须彻底理解硬件是如何工作的，以及软件设计需要遵循哪些铁律。这能避免后期调试时出现各种匪夷所思的问题。

2.1 SDMMC控制器架构与双卡支持原理

LPC55S6x的SDMMC控制器并非简单的“一对一”外设。如图1所示，其核心由几个关键单元构成：

• 总线接口单元（BIU）：负责与芯片内部的AHB总线对接，处理寄存器的读写以及DMA传输的发起与控制。这是数据进出CPU和内存的咽喉要道。
• 卡接口单元（CIU）：这是协议层的核心，负责生成符合SD/MMC/eMMC标准的时钟、命令和数据波形，并解析来自卡的响应。它内部包含状态机和FIFO。
• 内部DMA控制器：一个专为SDMMC设计的AHB主控DMA，能够在不占用CPU资源的情况下，在SD卡和系统内存之间搬运数据，极大提升吞吐量。

最关键的一点在于，虽然有两组物理引脚（SD0_CLK, SD0_CMD, SD0_D[7:0] 和 SD1_CLK, SD1_CMD, SD1_D[3:0]），但它们背后是同一个CIU和同一套寄存器。你可以把它想象成一个单核CPU，虽然可以连接两个显示器（SD卡），但同一时刻只能在一个显示器上输出内容。控制器通过寄存器中的CARD_NUMBER（卡号）位域来区分当前操作的对象是SD0还是SD1。

这种共享架构带来了一个至关重要的限制：对SD0和SD1的访问必须是严格串行的，绝不能并行或重叠。这意味着，你必须确保在对SD0发起一个命令（例如写一个块）并收到完整响应、结束事务之前，绝不能去操作SD1的寄存器或引脚。任何尝试交叉或同时访问的行为都会导致总线冲突、命令超时或数据损坏。这是整个软件设计需要围绕的“第一性原理”。

2.2 引脚配置与硬件连接实战

硬件连接是第一步。以LPCXpresso55S69开发板为例，板载的SD卡槽已经连接到了SD0引脚组。SD1的引脚则被引到了Arduino接口上，方便我们扩展。

引脚功能与配置要点：

1. 必需引脚：对于每个SD卡接口，以下引脚必须正确连接：

   • SDn_CLK：时钟线，主机输出。
   • SDn_CMD：命令/响应线，双向开漏。
   • SDn_D[3:0]：数据线，双向（SD1最多支持4位，SD0支持8位）。
   • SDn_CARD_DET_N：卡检测信号，低电平有效（卡插入时拉低）。
   • VCC和GND：电源，必须稳定。

2. 可选引脚：

   • SDn_WR_PRT：写保护检测。
   • SDn_POW_EN：卡槽电源使能控制。
   • SDn_CARD_INT_N：卡中断（仅eSDIO）。

3. IOCON配置：引脚的功能模式需要通过IOCON寄存器配置。对于SDMMC这类高速外设，配置不当会导致信号完整性差、通信失败。核心配置如下表所示：

实操心得：在飞线连接第二张SD卡时，除了信号线，一定要确保共地。不共地是导致通信不稳定、时而能识别时而不能的最常见原因之一。电源可以从开发板的3.3V引脚取，但要注意总电流负载。如果使用独立的SD卡模块，最好确保其电平转换芯片也是3.3V的。

2.3 软件实现的核心思想与策略

面对一个只支持SD0的SDK，我们的目标是添加对SD1的支持。最粗暴的方法是直接修改fsl_sdif.c、fsl_sdmmc_host.c等现有文件，但这会破坏SDK的原始状态，给未来SDK升级和维护带来灾难。

我们采用的策略是“增量添加，最小侵入”：

1. 创建新文件，而非修改旧文件：为SD1创建新的驱动文件（如fsl_sdif1.c/.h,fsl_sd1.c等），在其中实现与SD0对应的功能。这样，原有SD0的代码完全不受影响。
2. 复用与继承：SD1和SD0的差异很小，主要集中在几个寄存器的位设置上（如CARD_NUMBER）。因此，SD1的新函数可以大量复制SD0的代码，仅修改这些关键差异点。
3. 分层次实现：遵循SDK的驱动分层架构（HAL层 -> 主机层 -> 协议层），逐层为SD1添加支持，确保与现有架构兼容。

关键差异点梳理：

• PWREN (电源使能寄存器)：有独立的位控制SD0和SD1的电源。
• CLKENA (时钟使能寄存器)：有独立的位控制SD0和SD1的时钟输出。
• CDETECT (卡检测寄存器)：有独立的位反映SD0和SD1的卡插入状态。
• CTYPE (卡类型寄存器)：独立配置SD0和SD1的数据总线宽度（1/4/8位）。
• CMD (命令寄存器)的[20:16]位 (CARD_NUMBER)：这是最容易被忽略，也最关键的一点！在发送任何命令之前，必须在此位域指明这个命令是发给SD0(0)还是SD1(1)。SDK中默认的发送函数可能只设置了SD0。

我们的主要工作，就是在HAL层创建一个新的SDIF1_SetCommandRegister()函数，确保在发送命令时正确设置卡号，并在上层逐级封装这个能力。

3. 为SDK打补丁：逐层实现SD1驱动

现在，我们进入核心的软件实现环节。请准备好你的LPCXpresso55S69 SDK（例如v2.8.x或更高版本）和Keil MDK/IAR开发环境。

3.1 HAL层（硬件抽象层）扩展

HAL层直接操作寄存器，是驱动的基础。SDK中SDMMC的HAL层实现在fsl_sdif.c和fsl_sdif.h中。

第一步：创建新文件fsl_sdif1.c和fsl_sdif1.h我们将这两个文件放在与fsl_sdif.c相同的目录（\devices\LPC55S69\drivers\）下。.h文件主要用于声明函数，.c文件是具体实现。

fsl_sdif1.h关键内容：

#ifndef _FSL_SDIF1_H_ #define _FSL_SDIF1_H_ #include "fsl_common.h" #include "fsl_sdif.h" // 复用SDIF的类型和结构体定义 /* 为SD1重新声明关键的HAL函数 */ status_t SDIF1_SetCommandRegister(SDIF_Type *base, uint32_t cmd, uint32_t argument); // 其他如电源、时钟、检测函数，SDK的fsl_sdif.h中可能已有声明，如SDIF_EnableCard1Power等。 #endif

fsl_sdif1.c的核心——命令发送函数：这是整个补丁的“灵魂”。我们参考原有的SDIF_SetCommandRegister()函数来写。

status_t SDIF1_SetCommandRegister(SDIF_Type *base, uint32_t cmd, uint32_t argument) { // 参数检查... if (base == NULL) { return kStatus_InvalidArgument; } // 等待控制器就绪（与SD0函数相同） if ((base->STATUS & (SDIF_STATUS_DATA_BUSY_MASK | SDIF_STATUS_CMD_FIFO_FULL_MASK | SDIF_STATUS_DATA_FIFO_FULL_MASK | SDIF_STATUS_DATA_FIFO_AFULL_MASK)) != 0U) { return kStatus_SDIF_Busy; } // **关键区别：设置卡号为1 (SD1)** uint32_t cmdReg = (cmd & ~SDIF_CMD_CARD_NUMBER_MASK) | SDIF_CMD_CARD_NUMBER(1U); // 写入命令参数 base->CMD_ARG = argument; __DSB(); // 数据同步屏障，确保参数先写入 // 写入命令寄存器，触发命令发送 base->CMD = cmdReg; return kStatus_Success; }

代码解析：SDIF_CMD_CARD_NUMBER(1U)这个宏就是将数值1移位到CMD寄存器的[20:16]位。其他所有流程（参数写入、状态检查）都与SD0完全一致。这就是“复用”的精髓。

其他HAL函数：对于SDIF_EnableCard1Power(),SDIF_SetCard1BusWidth()等函数，SDK的fsl_sdif.h中可能已经提供了声明和实现（因为它们不涉及CMD寄存器），我们只需要确认并在新文件中调用即可。如果没有，则需要类似地创建。

3.2 主机层（Host Layer）适配

主机层在SDK的中间件中（\middleware\sdmmc\），它封装HAL层，提供更高级的、与协议无关的操作，如“发起一次传输”、“检测卡插入”。

创建新文件fsl_sdmmc_host1.c和fsl_sdmmc_host1.h放在\middleware\sdmmc\port\sdif\polling\目录下（因为我们以轮询模式为例）。

核心任务：实现SD1的传输函数我们需要创建一个SDMMC1HOST_TransferFunction()，它内部调用我们刚写的SDIF1_SetCommandRegister()。

sdmmc_host_transfer_t SDMMC1HOST_TransferFunction(void) { sdmmc_host_transfer_t transferFunc; transferFunc.transfer = SDMMC1HOST_Transfer; // 指向具体的传输实现函数 transferFunc.cardInserted = SDMMCHOST_DetectCard1InsertByHost; transferFunc.cardBusWidth = SDMMCHOST_SetCard1BusWidth; transferFunc.cardPower = SDMMCHOST_PowerOnCard1; // 这些函数需要实现或调用已有API transferFunc.cardReset = NULL; // 根据需求实现 // ... 其他函数指针赋值 return transferFunc; } static status_t SDMMC1HOST_Transfer(sdmmchost_t *host, sdmmchost_transfer_t *content) { // 这个函数是实际执行命令和数据传输的地方 // 其内部实现几乎可以完全复制 `SDMMCHOST_Transfer` (SD0的版本) // 但需要将所有调用 `SDIF_SetCommandRegister` 的地方，替换为 `SDIF1_SetCommandRegister` // 同时，确保在配置电源(host->power)、时钟(host->clock)时，操作的是SD1相关的寄存器位 // 这是一个细致但机械的替换过程。 }

注意事项：在复制修改SDMMCHOST_Transfer函数时，要特别注意所有与“卡选择”相关的逻辑。除了CMD寄存器，还有在配置CTYPE（总线宽度）、CLKENA（时钟）时，要确保操作的是SD1对应的控制位。一个稳妥的方法是，在函数开头，根据host结构体中可能新增的“cardIndex”成员，或者通过一个全局标志，来分支选择操作SD0还是SD1的寄存器位。在我们的示例中，由于是为SD1创建独立的函数，我们可以假设这个函数只操作SD1。

3.3 协议层（Protocol Layer）与板级配置

协议层实现了SD卡的上电、初始化、读写块等具体协议。SDK中对应文件是fsl_sd.c。

创建新文件fsl_sd1.c和fsl_sd1.h放在\middleware\sdmmc\src\目录下。这个文件将实现诸如SD1_Init(),SD1_ReadBlocks()等面向应用的高级API。

实现策略：由于fsl_sd.c中很多核心协议函数被声明为static（文件内可见），我们无法直接复用。这里有一个巧妙的办法：

1. 在fsl_sd1.c中，我们主要实现一个SD1_Init()函数。
2. 在SD1_Init()内部，我们需要调用协议层的底层初始化函数。我们可以通过**在fsl_sd.c文件末尾包含fsl_sd1.c**的方式来绕过static的限制。这样，fsl_sd1.c中的代码就能看到fsl_sd.c中的静态函数了。
3. SD1_Init()的工作流程是：
   • 调用SDMMC1HOST_TransferFunction()获取SD1的传输函数集。
   • 调用一个通用的、但传入SD1专属传输函数集的初始化例程（这个例程需要从fsl_sd.c中提取或重构）。

板级引脚初始化：在项目的板级支持包（BSP）文件（如board.c或pin_mux.c）中，你需要添加SD1引脚的初始化代码。这包括：

1. 配置相关引脚为SDMMC功能（通过IOCON的FUNC字段）。
2. 根据表2设置SLEW、DIGIMODE等属性，确保信号质量。
3. 初始化卡检测引脚（SD1_CARD_DET_N）为输入模式，并可能配置内部上拉。

你可以完全参考SD0引脚的初始化代码来写，只是将引脚名和功能号换成SD1的。

3.4 集成与工程配置

将所有新文件复制到SDK对应目录后，需要修改工程配置，让编译器找到它们。

1. 添加头文件路径：在IDE（如Keil）的工程设置中，确保包含了新头文件所在的目录（\middleware\sdmmc\inc\等）。
2. 添加源文件：将fsl_sdif1.c,fsl_sdmmc_host1.c,fsl_sd1.c添加到你的工程中。
3. 修改fsl_sd.c：在该文件末尾添加一行#include “fsl_sd1.c”。这是实现协议函数共享的关键一步。
4. 链接配置：确保无误。

4. 双卡访问实战与代码演示

现在，我们编写一个简单的main()函数来演示双卡访问。这个例程将依次初始化SD0和SD1，然后分别对它们进行读写验证。

#include “fsl_sd.h” // 包含SD0的API #include “fsl_sd1.h” // 包含我们新添加的SD1的API #include “board.h” #define BUFFER_SIZE (512) // 一个SD扇区的大小 int main(void) { BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitDebugConsole(); // 初始化串口用于打印 sd_card_t g_sd; // SD0句柄 sd_card_t g_sd1; // SD1句柄 uint8_t writeBuffer[BUFFER_SIZE]; uint8_t readBuffer[BUFFER_SIZE]; bool match = true; // 1. 初始化SD0 PRINTF(“\r\nInitializing SD0 card...\r\n”); if (SD_Init(&g_sd) != kStatus_Success) { PRINTF(“SD0 initialization failed!\r\n”); while(1); } PRINTF(“SD0 initialized successfully.\r\n”); PRINTF(“ Card Size: %llu MB\r\n”, (g_sd.blockCount * g_sd.blockSize) >> 20); // 2. 初始化SD1 (使用我们新增的API) PRINTF(“\r\nInitializing SD1 card...\r\n”); if (SD1_Init(&g_sd1) != kStatus_Success) { // 注意是SD1_Init PRINTF(“SD1 initialization failed!\r\n”); // 即使SD1失败，我们还可以继续操作SD0 } else { PRINTF(“SD1 initialized successfully.\r\n”); PRINTF(“ Card Size: %llu MB\r\n”, (g_sd1.blockCount * g_sd1.blockSize) >> 20); } // 3. 测试SD0 PRINTF(“\r\n--- Testing SD0 ---\r\n”); memset(writeBuffer, 0xAA, BUFFER_SIZE); // 填充测试数据 if (SD_WriteBlocks(&g_sd, writeBuffer, 0, 1) == kStatus_Success) { // 写第0个扇区 PRINTF(“SD0 write block 0 OK.\r\n”); if (SD_ReadBlocks(&g_sd, readBuffer, 0, 1) == kStatus_Success) { // 读第0个扇区 if (memcmp(writeBuffer, readBuffer, BUFFER_SIZE) == 0) { PRINTF(“SD0 read verification PASSED.\r\n”); } else { PRINTF(“SD0 read verification FAILED!\r\n”); match = false; } } } // **关键：确保SD0操作完全结束** // 在实际应用中，这里可能需要检查SD0的传输状态，或等待一小段时间。 // 4. 测试SD1 (如果初始化成功) if (g_sd1.isHostReady) { PRINTF(“\r\n--- Testing SD1 ---\r\n”); memset(writeBuffer, 0x55, BUFFER_SIZE); // 换一种测试数据 // 注意：这里使用SD1的API，例如 SD1_WriteBlocks (需要你在fsl_sd1.h中声明并实现) if (SD1_WriteBlocks(&g_sd1, writeBuffer, 0, 1) == kStatus_Success) { PRINTF(“SD1 write block 0 OK.\r\n”); if (SD1_ReadBlocks(&g_sd1, readBuffer, 0, 1) == kStatus_Success) { if (memcmp(writeBuffer, readBuffer, BUFFER_SIZE) == 0) { PRINTF(“SD1 read verification PASSED.\r\n”); } else { PRINTF(“SD1 read verification FAILED!\r\n”); match = false; } } } } if (match) { PRINTF(“\r\nAll tests passed!\r\n”); } else { PRINTF(“\r\nTest failed.\r\n”); } while(1) {} }

重要提示：上述代码中的SD1_WriteBlocks和SD1_ReadBlocks需要你在fsl_sd1.h/.c中参照SD0的SD_WriteBlocks和SD_ReadBlocks来实现。它们内部会调用我们为SD1定制的传输函数。

5. 调试心得与常见问题排查

在实际操作中，你几乎一定会遇到各种问题。以下是我在实现过程中踩过的坑和总结的排查思路。

5.1 硬件连接问题

• 症状：SD1完全无法识别，或时好时坏。
• 排查：
  1. 万用表检查：首先用万用表蜂鸣档，确保每根飞线都连接牢固，没有虚焊或断线。重点检查SD1_CMD和SD1_CLK。
  2. 电源与地：确保SD卡模块的VCC和GND与开发板连接正确且稳定。测量SD卡槽供电引脚电压是否为稳定的3.3V。
  3. 上拉电阻：SD总线的CMD和DATA线需要上拉电阻（通常4.7K-10KΩ）。很多SD卡模块已经集成。如果没有，需要在MCU引脚端添加外部上拉。
  4. 信号质量：如果条件允许，用示波器观察SD1_CLK和SD1_CMD的波形。时钟信号应干净、方波陡峭。在初始化阶段（400kHz低速模式）观察尤为重要。

5.2 软件配置问题

• 症状：SD1初始化失败，返回超时或CRC错误。
• 排查：
  1. 引脚复用配置：百分之八十的问题出在这里！反复检查IOCON配置。确认FUNC字段是否正确设置为SDMMC功能。务必确认SLEW和DIGIMODE位已使能。
  2. 卡号设置遗漏：在SDIF1_SetCommandRegister函数中，是否正确地设置了CARD_NUMBER=1？在调试时，可以在发送CMD0（复位命令）前后读取CMD寄存器，验证该位是否被正确写入。
  3. 时钟与电源使能：确认在初始化SD1时，调用了SDIF_EnableCard1Power()和SDIF_EnableCard1Clock()。可以在这些函数前后读取PWREN和CLKENA寄存器确认。
  4. 顺序与状态：严格遵守“串行访问”原则。在操作SD1之前，确保SD0的控制器处于空闲状态（STATUS寄存器中没有BUSY标志）。可以在切换卡操作前加入一个短暂的延时或状态查询循环。

5.3 文件系统集成问题

• 症状：底层读写块成功，但挂载FATFS等文件系统失败。
• 排查：
  1. 磁盘驱动层：文件系统需要你提供disk_read和disk_write函数。你需要为SD0和SD1分别实现两个独立的“磁盘”（例如Disk 0和Disk 1）。确保在文件系统的磁盘初始化函数中，正确调用对应的SD_Init或SD1_Init。
  2. 工作区独立：每个磁盘需要独立的FATFS对象和缓冲区。不要混用。
  3. 格式化：新的SD卡可能需要先用f_mkfs函数格式化才能挂载。可以在代码中先尝试挂载，如果失败再格式化（注意会清空数据！）。

5.4 性能与稳定性优化

• 降低初始时钟频率：在SD卡初始化阶段（识别和OCR验证），将SDMMC时钟分频系数设得大一些，使用较低的频率（如400kHz），可以提高在长飞线或干扰环境下的识别成功率。初始化完成后再切换到高速模式。
• 增加超时重试：在卡检测和命令发送循环中，适当增加超时计数，给硬件更长的响应时间。
• DMA配置：如果使用DMA进行块数据传输，确保为SD0和SD1的DMA传输正确配置了不同的通道或流，并管理好它们的启动与完成中断。在轮询模式下，则无需考虑此问题。

实现LPC55S6x的双SD卡访问，更像是一次对MCU外设资源共享机制的深度实践。它考验的不仅仅是对SDMMC协议的理解，更是对现有SDK架构的把握和进行“外科手术式”扩展的能力。整个过程的核心在于“理解差异，增量添加，严格串行”。当你看到终端上先后打印出两张SD卡的容量信息，并完成读写校验时，那种对硬件和软件协同工作的掌控感，正是嵌入式开发的乐趣所在。这个方案为需要在单控制器上扩展双存储的应用提供了一个稳定可靠的参考，你可以在此基础上，进一步探索双卡镜像、负载均衡等更高级的应用场景。