首页/资讯中心/详情

瑞萨RA MCU I2C从机驱动配置与实战避坑指南

瑞萨RA MCU I2C从机驱动配置与实战避坑指南
📅 发布时间：2026/6/29 7:06:42

1. 瑞萨RA MCU I2C从机驱动：从配置到实战的深度解析

在嵌入式系统开发中，I2C总线因其简洁的两线制（SDA和SCL）和灵活的多主多从架构，成为了连接传感器、EEPROM、RTC等外设的“黄金标准”。然而，当我们从主控MCU的角色切换到从设备时，开发思路和实现细节会发生显著变化。瑞萨电子的RA系列MCU，凭借其强大的性能和丰富的生态，在各类物联网终端、智能传感器中应用广泛。其官方提供的Flexible Software Package（FSP）框架，将I2C从机功能封装成了高度模块化、事件驱动的驱动，这极大地简化了开发，但也引入了一套全新的API和配置逻辑。如果你正在为RA MCU开发一个I2C从设备，比如一个需要上报数据的温湿度传感器模块，或者一个接收配置命令的执行器，那么深入理解FSP中的I2C Slave驱动至关重要。本文将基于FSP官方手册，结合我多年的嵌入式实战经验，为你拆解r_iic_slave和r_iica_slave驱动的每一个配置项、API的调用时机、回调函数的编写要点，以及那些手册里不会明说，但实际调试中一定会遇到的“坑”。

2. I2C从机驱动模块选型与核心概念辨析

在RA FSP中，你会遇到两个I2C从机驱动模块：r_iic_slave和r_iica_slave。这并非冗余，而是针对不同硬件IP核的适配。简单来说，r_iic_slave驱动面向的是RA2/RA4/RA6/RA8系列MCU中常见的IIC（或称为RIIC）外设模块。而r_iica_slave则专门用于RA0系列等MCU中集成的IICA外设模块。两者在API层面保持了高度一致，都遵循i2c_slave_api_t接口，这意味着你的上层应用代码在两者间迁移时，几乎无需改动。但在底层配置和部分特性支持上，它们存在差异。

核心差异点解析：

  1. 支持器件：r_iic_slave支持RA2、RA4、RA6、RA8全系列。r_iica_slave仅支持RA0系列（如RA0E1, RA0E2等）。选型的第一步就是确认你手头MCU的型号和数据手册中标注的I2C外设类型。
  2. DTC支持：r_iic_slave支持通过DTC（数据传输控制器）进行自动数据传输，这可以解放CPU，减少中断开销，对于大数据量传输尤其有用。而r_iica_slave的说明中明确标注“DTC does not support IICA”，这意味着所有数据传输都必须通过CPU参与的中断服务例程来完成。
  3. 配置参数：在FSP配置器（如e² studio或RASC）中，两者的配置属性页有所不同。例如，r_iica_slave有独立的“Signal Rising Time”和“Signal Falling Time”用于时序微调，而r_iic_slave则通过“Digital Noise Filter Stage Select”来抑制噪声。r_iic_slave还支持“General Call”（广播地址0x00响应）和“10-bit slave addressing”作为可选的构建时配置，而r_iica_slave中这些是运行时配置选项。

为什么需要事件驱动回调？这是FSP I2C从机驱动设计的精髓。与轮询或简单中断不同，FSP采用了一种状态机+回调通知的模型。从机硬件在检测到匹配的地址、接收到一个字节、发送完一个字节、产生错误等关键节点，都会触发中断，驱动层的中断服务程序（ISR）会判断当前状态，然后调用你预先注册的回调函数，并传入具体的事件（如I2C_SLAVE_EVENT_RX_REQUEST）。你的应用程序逻辑就在这个回调函数里，根据不同事件决定是调用R_IIC_SLAVE_Read去读取主设备发来的数据，还是调用R_IIC_SLAVE_Write准备数据供主设备读取。这种设计将底层硬件时序与上层应用逻辑清晰解耦，使得代码结构非常清晰，易于维护。

3. FSP配置器详解：从零搭建一个I2C从机工程

理论说再多，不如动手配一遍。我们以更通用的r_iic_slave为例，在RASC（Renesas Advanced Software Configurator）中走一遍配置流程。假设我们要创建一个地址为0x50（7位地址）、工作在标准模式（100kHz）的从设备。

3.1 新建堆栈与基础参数配置

在项目的“Stacks”标签页下，点击“New Stack” -> “Connectivity” -> “I2C Slave (r_iic_slave)”。这会自动生成一个驱动实例，例如g_i2c_slave0。

接下来，我们需要关注属性（Properties）视图中的关键配置：

  • Name：实例名，保持默认g_i2c_slave0即可，代码中会用到。
  • Channel：选择I2C通道。这里有个大坑：你必须查阅MCU的数据手册引脚分配表，确认你计划使用的SDA和SCL引脚对应的物理通道号。例如，P400和P401可能对应Channel 0。选错通道会导致代码无法控制正确的物理引脚。
  • Rate：通信速率。有Standard（100kHz）、Fast-mode（400kHz）、Fast-mode plus（1MHz）可选。注意：这里的速率是“目标值”。实际速率取决于PCLKB（外设时钟B）的频率。配置器会根据你设置的PCLKB频率，计算并应用一个小于或等于目标值的、实际可达到的最高速率。如果PCLKB频率过低，可能连100kHz都达不到，配置器会报错。计算出的实际理论速率会在生成的iic_slave_extended_cfg_t结构体注释中写明，务必检查。
  • Slave Address：设置你的从机地址（7位模式）。例如输入0x50。注意，这是左对齐的7位地址，驱动内部会处理移位。如果你配置为10位地址模式，这里应填写完整的10位地址值。
  • Address Mode：选择7-Bit或10-Bit。10位地址模式可以连接更多设备，但协议稍复杂。
  • General Call：是否响应广播地址0x00。如果使能，当主设备发送地址0x00时，你的从机也会响应。这在需要同时向总线上所有从机广播命令时有用。
  • Clock Stretching：这是从机能力的核心。如果使能，从机可以通过在回调函数中不立即调用Read/Write API（即保持SCL线拉低）来“拉伸时钟”，告诉主设备“我还没准备好，请等待”。这对于从机需要时间准备数据（例如从低速传感器读取）的场景至关重要。如果禁用，从机必须在硬件规定的时间内响应，否则可能导致通信错误。

3.2 中断与时钟配置的玄机

  • Interrupt Priority Level：这里包含两组中断优先级设置。

    • Transmit, Receive, and Transmit End：对应TXI（发送缓冲空中断）、RXI（接收缓冲满中断）、TEI（发送结束中断）。这三个中断通常用于处理正常的数据传输流程。
    • Error：对应ERI（错误中断），用于处理仲裁丢失、总线错误等情况。重要经验：手册中特别指出，在使能了时钟拉伸且进行“主写-从读”操作时，如果从机需要在接收完最后一个数据字节后进行时钟拉伸，那么ERI中断的优先级必须设置得高于或等于TXI/RXI/TEI的优先级。这是为了确保错误处理（可能包含停止条件）能优先于下一个可能启动的事务，避免总线状态混乱。在大多数应用中，我会将ERI设置为最高或次高优先级，TXI/RXI/TEI设置为稍低的优先级。

  • Internal Reference Clock：内部参考时钟分频选择。这个时钟仅用于决定I2C模块内部数字噪声滤波器的采样频率。通常保持默认PCLKB / 1即可。更高的分频（更低的采样频率）抗噪能力更强，但会限制最高通信速率。如果你的环境噪声较大，可以尝试增加分频数。

  • Digital Noise Filter Stage Select：数字噪声滤波级数选择。这是硬件上的滤波器，可以滤除SDA和SCL线上的毛刺。级数越高，滤波效果越好，但也会引入微小的信号延迟。在标准速率下，3-stage filter（三级滤波）是稳健的默认选择。在高速率（如1MHz）或长走线情况下，可能需要根据信号完整性测试调整此设置。

3.3 引脚配置与DTC使能

  • Pin Configuration：在“Pins”标签页，找到你选择的Channel对应的SDA和SCL引脚。通常需要配置为“Open Drain”（开漏）模式，并启用上拉电阻（内部或外部）。开漏输出和上拉电阻是I2C总线正常工作的物理基础，忘记配置上拉会导致信号无法拉高，通信失败。
  • DTC on Transmission and Reception：这是一个“Build Time Configuration”（构建时配置），在fsp_cfg/r_iic_slave_cfg.h中定义。如果使能，驱动会为发送和接收分别初始化DTC实例。当DTC使能后，在回调函数中调用R_IIC_SLAVE_Read/Write时，驱动会自动配置DTC，数据会在硬件和缓冲区之间自动搬运，无需CPU逐个字节处理，大大减轻中断负担。使用DTC的前提是：DTC的时钟频率必须配置得高于上面设置的“Internal Reference Clock”。

配置完成后，点击“Generate Project Content”，FSP就会为你生成初始化代码、配置结构体以及中断向量表配置。你的主要工作，就变成了实现那个核心的回调函数。

4. 核心API与回调函数实战编程指南

生成的代码骨架提供了基础，但要让它真正工作起来，你需要深入理解每个API的行为和回调函数的编写逻辑。我们结合一个典型的“从机收发”场景来剖析。

4.1 驱动生命周期管理：Open与Close

任何FSP驱动的使用都始于Open，终于Close。

// 驱动控制块和配置结构体（通常由FSP在生成的头文件中声明为extern） extern iic_slave_instance_ctrl_t g_i2c_slave_ctrl; extern i2c_slave_cfg_t g_i2c_slave_cfg; fsp_err_t err = R_IIC_SLAVE_Open(&g_i2c_slave_ctrl, &g_i2c_slave_cfg); if (FSP_SUCCESS != err) { // 处理错误：可能是通道无效、参数错误、时钟速率无法达到等 // 例如，打印错误代码或进入故障安全状态 }

R_IIC_SLAVE_Open函数会初始化硬件寄存器、配置中断、并根据你的配置计算实际的波特率。如果返回FSP_ERR_INVALID_ARGUMENT，很可能是中断优先级设置错误（ERI优先级低于TXI等）。如果返回其他错误，请根据手册的“Return values”部分排查。

在应用程序退出或需要释放资源时，调用R_IIC_SLAVE_Close。这是一个好习惯，虽然对于很多嵌入式系统来说，设备从不关闭。

4.2 灵魂所在：回调函数的实现

回调函数是你应用逻辑的入口。它的原型是固定的：

void i2c_slave_callback(i2c_slave_callback_args_t *p_args);

p_args结构体中包含了事件类型event、已传输的字节数bytes以及用户上下文指针p_context（你在配置中设置的）。

回调函数的编写必须遵循“事件-响应”模式，并且要快进快出，因为它是在中断上下文中执行的。长时间阻塞会导致错过后续总线事件，甚至引发超时。下面是一个包含基本错误处理和状态管理的增强版回调示例：

// 定义一些全局状态或队列，用于在回调与主循环间传递数据 volatile uint8_t g_slave_rx_buffer[256]; volatile uint32_t g_slave_rx_index = 0; volatile bool g_slave_rx_complete = false; volatile uint8_t g_slave_tx_buffer[256]; volatile uint32_t g_slave_tx_index = 0; volatile uint32_t g_slave_tx_length = 0; void i2c_slave_callback(i2c_slave_callback_args_t *p_args) { fsp_err_t err = FSP_SUCCESS; switch (p_args->event) { case I2C_SLAVE_EVENT_RX_REQUEST: // 主设备要写数据给本从机（第一次请求） // 准备读取数据，假设我们一次最多接收256字节 err = R_IIC_SLAVE_Read(&g_i2c_slave_ctrl, (uint8_t*)&g_slave_rx_buffer[0], 256); // 注意：这里传入的字节数是“本次准备接收的最大字节数”。 // 主设备可能不会写满256字节，实际写入的字节数会在RX_COMPLETE事件中通过p_args->bytes获知。 assert(FSP_SUCCESS == err); g_slave_rx_index = 0; // 重置接收索引 g_slave_rx_complete = false; break; case I2C_SLAVE_EVENT_RX_MORE_REQUEST: // 主设备在连续写，请求发送更多数据（例如，主设备在写一个长数据包） // 计算剩余缓冲区空间 uint32_t remaining_space = 256 - g_slave_rx_index; if (remaining_space > 0) { // 继续从当前位置开始接收 err = R_IIC_SLAVE_Read(&g_i2c_slave_ctrl, (uint8_t*)&g_slave_rx_buffer[g_slave_rx_index], remaining_space); assert(FSP_SUCCESS == err); } else { // 缓冲区已满，必须发送NACK。通过请求读取0字节来实现。 err = R_IIC_SLAVE_Read(&g_i2c_slave_ctrl, NULL, 0); assert(FSP_SUCCESS == err); // 同时，可以设置一个错误标志，通知主循环缓冲区溢出。 } break; case I2C_SLAVE_EVENT_RX_COMPLETE: // 一次接收事务完成（主设备发送了停止位或重复起始位） // p_args->bytes 包含了本次事务中总共接收到的字节数。 // 注意：这个字节数是从本次RX_REQUEST或RX_MORE_REQUEST开始累计的，不是全局累计。 g_slave_rx_index += p_args->bytes; // 更新全局接收索引 g_slave_rx_complete = true; // 通知主循环有新数据 // 可以在这里将数据拷贝到安全区域，或者触发一个任务信号量。 break; case I2C_SLAVE_EVENT_TX_REQUEST: // 主设备要读本从机的数据（第一次请求） // 准备要发送的数据。例如，假设我们有10字节数据要发送。 g_slave_tx_length = 10; for (int i=0; i<g_slave_tx_length; i++) { g_slave_tx_buffer[i] = i; // 填充示例数据 } g_slave_tx_index = 0; err = R_IIC_SLAVE_Write(&g_i2c_slave_ctrl, (uint8_t*)&g_slave_tx_buffer[g_slave_tx_index], g_slave_tx_length); assert(FSP_SUCCESS == err); break; case I2C_SLAVE_EVENT_TX_MORE_REQUEST: // 主设备在连续读，请求更多数据 // 检查是否还有数据要发送 if (g_slave_tx_index < g_slave_tx_length) { uint32_t remaining_bytes = g_slave_tx_length - g_slave_tx_index; err = R_IIC_SLAVE_Write(&g_i2c_slave_ctrl, (uint8_t*)&g_slave_tx_buffer[g_slave_tx_index], remaining_bytes); assert(FSP_SUCCESS == err); } else { // 没有更多数据了。根据I2C协议，从机在最后一个字节后发送NACK？不对，从机发送完数据后，主设备会发送NACK/停止位。 // 实际上，当从机没有更多数据时，它应该在TX_MORE_REQUEST时不做响应（不调用Write），但这可能导致超时。 // 更安全的做法是，发送一个填充值（如0xFF）或者提前结束传输（需要主设备配合）。 // 一种常见模式：从机始终准备好一个默认数据（如0x00或0xFF）来响应意外的TX_MORE_REQUEST。 err = R_IIC_SLAVE_Write(&g_i2c_slave_ctrl, (uint8_t*)&dummy_byte, 1); assert(FSP_SUCCESS == err); } break; case I2C_SLAVE_EVENT_TX_COMPLETE: // 一次发送事务完成 // 可以更新发送索引，或者准备下一批数据。 g_slave_tx_index = g_slave_tx_length; // 标记所有数据已发送 break; case I2C_SLAVE_EVENT_ABORTED: // 发生错误：仲裁丢失、总线错误、检测到停止位等。 // 必须进行错误恢复：重置缓冲区索引，清除状态标志。 g_slave_rx_index = 0; g_slave_tx_index = 0; g_slave_rx_complete = false; // 可以考虑点亮一个错误LED，或者记录错误日志。 break; case I2C_SLAVE_EVENT_GENERAL_CALL: // 主设备发送了广播地址(0x00)。只有使能了General Call配置才会收到此事件。 // 处理广播命令。例如，复位所有从机，或同步时间。 // 通常也需要调用R_IIC_SLAVE_Read来读取广播数据。 err = R_IIC_SLAVE_Read(&g_i2c_slave_ctrl, (uint8_t*)&g_slave_rx_buffer[0], 256); assert(FSP_SUCCESS == err); break; default: // 未知事件，理论上不应发生。 break; } }

4.3 数据收发API：Read与Write的微妙之处

R_IIC_SLAVE_Read和R_IIC_SLAVE_Write是你在回调函数中响应主设备请求的工具。

  • R_IIC_SLAVE_Read(p_ctrl, p_dest, bytes)：当主设备要写数据给从机（即主设备发送，从机接收）时，你在RX_REQUEST或RX_MORE_REQUEST事件中调用此函数。p_dest是目标缓冲区指针，bytes是你准备接收的最大字节数。这个调用会配置硬件，开始接收数据。关键点：如果你是一个“只写”从机（例如一个显示器），当收到读请求时，你应该调用Read(p_ctrl, NULL, 0)，这会使得从机在地址确认后立即发送一个NACK，主设备通常会因此停止或转向下一个从机。
  • R_IIC_SLAVE_Write(p_ctrl, p_src, bytes)：当主设备要从从机读取数据（即主设备接收，从机发送）时，你在TX_REQUEST或TX_MORE_REQUEST事件中调用此函数。p_src是源数据缓冲区指针，bytes是你准备发送的字节数。调用后，硬件会开始发送这些数据。

关于“More Request”事件：这是实现流式传输或大数据包传输的关键。主设备在一次通信中（不释放总线，即使用重复起始条件）连续读取或写入多个数据块时，从机会在完成一个Read/Write调用对应的数据传输后，收到XXX_MORE_REQUEST事件，这意味着主设备还想继续。你必须再次调用对应的API来服务这个请求，否则总线会超时。

5. 高级特性与实战避坑指南

5.1 时钟拉伸（Clock Stretching）的实战应用与陷阱

时钟拉伸是从机控制通信节奏的“刹车”机制。当从机需要更多时间准备数据（例如，从低速ADC读取一个值）时，它可以在收到请求后，在回调函数中不立即调用Read或Write，而是先设置一个标志，然后退出回调。此时，硬件会保持SCL线为低（拉伸时钟），主设备会等待。当从机准备好数据后（例如，在主循环中检测到ADC转换完成），再调用Read或Write，硬件便会释放SCL，通信继续。

配置要点：必须在FSP配置器中使能“Clock Stretching”选项。

代码模式示例：

volatile bool g_data_ready = false; volatile bool g_stretch_clock = false; void i2c_slave_callback(i2c_slave_callback_args_t *p_args) { if (p_args->event == I2C_SLAVE_EVENT_TX_REQUEST) { if (!g_data_ready) { // 数据还没准备好，不调用Write，让硬件拉伸时钟 g_stretch_clock = true; // 触发一个任务或标志，让主循环去准备数据 trigger_data_preparation(); return; // 关键：直接返回，不调用Write！ } else { // 数据已准备好，正常发送 R_IIC_SLAVE_Write(..., tx_buffer, data_length); g_stretch_clock = false; } } } // 在主循环或另一个任务中 void main_loop(void) { if (g_stretch_clock && g_data_ready) { // 数据准备完毕，现在调用Write来释放时钟，继续通信 // 注意：我们需要知道要发送什么数据。通常需要根据之前保存的上下文来决定。 R_IIC_SLAVE_Write(&g_i2c_slave_ctrl, ...); g_stretch_clock = false; } }

避坑指南：

  1. 超时风险：主设备和从机都有内部超时机制。如果从机拉伸时钟时间过长，任何一方超时都会导致通信失败。务必确保数据准备过程在合理时间内完成。
  2. 中断优先级：如前所述，使用时钟拉伸时，务必确保ERI错误中断的优先级不低于TXI/RXI/TEI中断优先级。
  3. 状态管理：在拉伸期间，从机状态必须妥善管理。确保在数据准备好后，能准确地恢复并服务正确的请求（TX还是RX？是第几个字节？）。这通常需要借助p_context参数传递状态机或队列信息。

5.2 使用DTC实现“零CPU开销”传输

对于大数据量传输，使用DTC可以显著提升系统效率。配置使能“DTC on Transmission and Reception”后，你需要在FSP配置器中正确配置DTC通道（通常驱动会自动关联）。在代码中，你几乎感知不到DTC的存在，Read和WriteAPI的调用方式不变。区别在于，当你在回调中调用R_IIC_SLAVE_Read(p_dest, bytes)时，驱动内部会配置DTC，将接收到的数据自动搬运到p_dest指向的缓冲区，搬运字节数为bytes。发送过程同理。

注意事项：

  1. 缓冲区对齐与大小：确保p_dest或p_src指向的缓冲区在内存中对齐良好（通常是4字节对齐），并且大小足够。DTC传输可能会对性能有轻微影响，但通常利大于弊。
  2. DTC时钟：再次强调，DTC模块的工作时钟频率必须高于I2C从机模块的“Internal Reference Clock”。
  3. 传输完成判定：即使使用DTC，传输完成的通知（TX_COMPLETE/RX_COMPLETE事件）仍然通过回调函数产生。DTC只是负责数据搬运，不改变事件驱动的编程模型。

5.3 10位地址模式与广播地址

  • 10位地址：在配置中选择“Address Mode”为10-Bit，并在“Slave Address”中填写10位地址值（例如0x123）。10位地址的通信过程比7位地址多一个字节，但驱动已经处理了这些细节，对你的回调函数逻辑没有影响。
  • 广播地址（General Call）：使能此功能后，从机会响应地址0x00。这在需要对总线上多个设备进行同步操作（如全局复位、广播时间校准）时非常有用。在回调函数中，你需要处理I2C_SLAVE_EVENT_GENERAL_CALL事件，通常也是调用Read来获取广播数据。

6. 调试技巧与常见问题排查实录

即使配置和代码看起来完美，实际调试I2C从机也常会遇到问题。以下是我在多个项目中总结的排查清单：

问题1：从机根本不响应（用逻辑分析仪看不到ACK）

  • 检查清单：
    1. 引脚配置：SDA和SCL是否配置为正确的复用功能（I2C）和开漏模式？外部上拉电阻（通常4.7kΩ）是否接上？这是最常见的问题。
    2. 地址匹配：主设备发送的地址（包括读写位）是否与从机配置的地址完全一致？注意7位地址在总线上是左移一位的。
    3. 时钟和初始化：R_IIC_SLAVE_Open是否成功返回？用调试器检查返回值。系统时钟PCLKB是否正确配置并运行？如果时钟没起来，外设无法工作。
    4. 中断：对应的I2C通道中断（RXI, TXI, TEI, ERI）是否在NVIC中被启用？FSP的Open函数通常会做，但双重检查无害。

问题2：能收到地址ACK，但数据收发失败，或很快进入ABORTED状态

  • 检查清单：
    1. 回调函数未及时响应：在RX_REQUEST/TX_REQUEST事件中，你是否调用了Read/Write？如果没调用，从机会发送NACK或超时。确保每个请求事件都有对应的API调用。
    2. 缓冲区与长度：传递给Read/Write的缓冲区指针是否有效？长度参数是否为0？长度为0的Read会导致发送NACK。
    3. 时钟拉伸冲突：如果你使能了时钟拉伸，但在回调中既没有调用API也没有采取其他措施，SCL线会被一直拉低，导致主设备超时。检查你的拉伸逻辑。
    4. 中断优先级：特别是ERI中断优先级是否设置正确？错误的优先级可能导致总线错误无法及时处理。
    5. 电源与噪声：用示波器观察SDA/SCL波形。是否有过冲、振铃或毛刺？地线是否良好？电源是否干净？噪声可能导致数据错位，触发错误中断。

问题3：通信不稳定，偶尔丢数据或出错

  • 检查清单：
    1. 总线负载与上拉电阻：总线上设备太多或走线太长，会导致容性负载过大，信号边沿变缓。尝试减小上拉电阻值（如从4.7kΩ降到2.2kΩ），但注意会增加功耗。
    2. 数字噪声滤波器：适当增加“Digital Noise Filter Stage Select”的级数，可以有效滤除短脉冲噪声。
    3. 速率与时钟：确认实际通信速率是否在硬件和布线允许的范围内。过高的速率在长距离或干扰环境下容易出错。查看生成的iic_slave_extended_cfg_t结构体注释中的实际计算速率。
    4. 软件竞争条件：回调函数和主循环共享的全局变量（如缓冲区、索引）是否使用了volatile关键字？在读写这些变量时，是否需要关中断进行保护？特别是在使用DTC时，DTC可能在后台修改缓冲区。

问题4：使用DTC时，数据错位或丢失

  • 检查清单：
    1. 缓冲区管理：DTC传输是异步的。当你调用Read(p_dest, bytes)后，DTC开始工作，但p_dest指向的缓冲区在传输完成前（即收到RX_COMPLETE事件前）不能被其他代码修改。你需要设计双缓冲区或环形缓冲区。
    2. 传输大小：检查FSP_ERR_INVALID_SIZE错误。DTC对传输数据块的大小可能有对齐要求或最大值限制，请参考MCU的DTC章节数据手册。
    3. 时钟配置：确认DTC时钟频率高于I2C的“Internal Reference Clock”。

调试I2C，一个逻辑分析仪或带有I2C解码功能的示波器是必不可少的。它能直观地展示起始位、地址、数据、ACK/NACK和停止位，让你快速定位是协议层问题还是软件逻辑问题。从机调试时，可以先用一个已知良好的I2C主设备（如另一个MCU或专业的I2C主机工具）来测试你的从机，排除主设备端的干扰因素。