嵌入式MCU性能与功耗评测实战：基于LPC86x的CoreMark与动态电流测量-平芜编程栈

1. 项目概述与核心价值

在嵌入式开发领域，选型一颗微控制器（MCU）时，我们最常纠结的两个问题往往是：“它的性能到底怎么样？”以及“它跑起来到底有多费电？”。这两个问题直接关系到产品的响应速度、功能复杂度和电池续航能力。然而，面对厂商数据手册上琳琅满目的参数和宣传语，我们常常感到无从下手，缺乏一个客观、可横向比较的“标尺”。这就是CoreMark基准测试的价值所在。它不是什么高深的理论，而是一套由EEMBC（嵌入式微处理器基准评测协会）制定的、业界公认的“标准考题”，专门用来给CPU和MCU“打分”。这个分数，就是CoreMark分数，它量化了处理器执行一系列标准化算法（如链表操作、矩阵运算、状态机等）的效率，单位是每秒迭代次数。分数越高，意味着在相同主频下，处理器的核心计算效能越强。

但光有性能分数还不够。对于电池供电的物联网节点、便携式设备而言，“每一点性能需要付出多少功耗代价”同样至关重要。这就是为什么我们需要将CoreMark性能测试与动态功耗（Active Power Consumption）测量结合起来。通过这套组合拳，我们不仅能知道MCU“跑得快不快”，还能精确地知道它“跑得省不省电”，从而在性能与功耗之间找到那个最佳的平衡点，实现最优的能效比（Performance per Watt）。

本次实践，我们聚焦于恩智浦（NXP）的LPC86x系列MCU。这是一款基于Arm Cortex-M0+内核的32位微控制器，主打低成本与高集成度，最高运行频率60MHz，内置Flash和SRAM，并集成了丰富的通信接口和模拟外设，是许多消费电子和工业控制应用的理想选择。我将手把手带你，在Keil MDK、IAR EWARM和MCUXpresso这三款主流开发环境下，为LPC86x搭建CoreMark测试工程，并利用LPCXpresso860-MAX开发板，同步完成性能评分与动态电流的实测。整个过程涉及代码移植、编译器优化配置、硬件板卡设置以及数据解读，我会把每一步的原理、操作细节和我踩过的坑都讲清楚。无论你是正在评估LPC86x，还是想系统学习嵌入式性能评测方法，这篇文章都能给你提供一份可直接复现的“工程指南”。

2. 测试环境搭建与工程配置解析

进行基准测试，第一步不是急着写代码，而是搭建一个可靠、可复现的测试环境。这就像做科学实验，仪器和步骤的标准化决定了结果的公信力。对于CoreMark测试，我们需要准备两样东西：一是符合EEMBC规范的CoreMark源码包，二是针对目标MCU（这里是LPC86x）和开发环境适配好的工程框架。NXP提供的应用笔记和软件包已经为我们做好了后者，我们的任务是将两者正确“嫁接”起来。

2.1 CoreMark源码获取与工程结构理解

首先，我们需要从EEMBC官网获取最权威的CoreMark源码。访问https://www.eembc.org/coremark，找到下载链接。这里有个小技巧：EEMBC的CoreMark实现是开源的，通常托管在GitHub上。下载后，你会得到一个包含多个C源文件和头文件的压缩包。核心文件包括core_list_join.c,core_matrix.c,core_state.c,core_util.c,core_main.c以及coremark.h。这些文件实现了CoreMark基准测试的算法内核，是“标准考题”本身，我们原则上不应修改。

而要让这份“标准考题”能在LPC86x上运行起来，我们需要提供“答题纸”和“考场规则”，这就是“移植层”文件：core_portme.c和core_portme.h。这两个文件需要我们自己根据目标平台进行适配，主要包括：

计时器接口：CoreMark需要测量执行时间来计算分数。我们需要提供高精度计时器的初始化、启动、停止和读取函数。
输出接口：测试结果需要打印出来，通常是重定向printf到串口。
内存分配：定义堆栈大小和测试数据的内存空间。
多核支持（可选）：对于单核Cortex-M0+，这部分通常忽略。

NXP提供的SDK 2.11.1基础工程已经为我们准备好了针对LPC86x的移植层文件初稿，但我们需要将其与下载的CoreMark主文件整合。

2.2 多IDE环境下的工程文件整合

嵌入式开发的一个现实是，团队可能使用不同的集成开发环境（IDE）。为了确保测试结果的可比性，我们需要在Keil MDK、IAR EWARM和MCUXpresso中都完成相同的配置。虽然操作界面不同，但背后的逻辑是相通的。

2.2.1 主文件导入与项目添加

以Keil MDK为例，NXP提供的工程目录coremark_mdk下通常已有基本的驱动和启动文件。我们需要将下载的CoreMark主文件（core_list_join.c等）复制到source目录下。然后，在Keil的Project窗口中，右键点击对应的源文件组（如Source Group 1），选择“Add Existing Files to Group...”，将这些文件一一添加进去。这个步骤看似简单，但容易出错的地方是文件路径包含中文或特殊字符，以及忘记添加头文件路径。

对于IAR EWARM，过程类似，文件放入coremark_iar\source，然后在Workspace中右键点击文件组，选择“Add” -> “Add Files...”。MCUXpresso则更为自动化，通常只需将文件复制到coremark_MCUXpresso\coremark\source目录下，然后在IDE中右键点击项目，选择“Refresh”，IDE会自动识别新文件并将其加入工程索引。

实操心得：我建议在复制文件前，先在资源管理器中整理好CoreMark源码的文件夹结构。可以创建一个coremark_src文件夹，里面再分core（放主文件）和port（放移植文件）两个子目录。这样在多个IDE工程间同步和更新源码时会非常清晰，不易混乱。

2.2.2 移植层文件的重构与适配

接下来是关键一步：处理移植文件。从CoreMark源码包的coremark_main\simple目录下找到core_portme.c和core_portme.h。但请注意，我们不能直接使用这个通用版本。NXP提供的工程中，在source\port_lpc860目录下已经有了针对LPC86x修改过的版本。我们的任务是确保这个版本是正确的，并且包含了必要的LPC86x硬件抽象层（HAL）驱动调用。

你需要打开core_portme.c，重点检查以下几个函数：

portable_init()：这里应该初始化系统时钟、调试串口以及CoreMark所需的高精度定时器（例如SysTick或某个通用定时器）。
start_time()/stop_time()/get_time()：这些函数用于控制计时器。对于Cortex-M，通常使用SysTick的周期计数或DWT（Data Watchpoint and Trace）单元的CYCCNT计数器来获得CPU周期数，精度最高。
uart_putchar()或重定向的printf()：确保串口输出功能正常，这是看到测试结果的唯一途径。

我个人的习惯是，在portable_init()里不仅初始化硬件，还会通过串口打印一段启动信息，包含编译时间、优化等级等，便于后续追溯测试条件。

2.3 编译器与链接器关键配置详解

工程文件添加完毕后，编译器的设置直接决定了测试结果的合法性与准确性。CoreMark官方对测试环境有严格规定，我们必须遵守。

2.3.1 代码执行区域设置

测试代码应该从哪里执行？Flash还是RAM？这会影响性能。为了模拟大多数实际应用场景（代码存储在Flash中执行），我们选择从内部Flash执行。这需要在链接器（Linker）配置中指定。

Keil MDK：进入“Options for Target” -> “Linker”选项卡。在“Scatter File”中，选择工程目录下的LPC865_flash.scf文件。这个分散加载文件定义了代码、数据在Flash和RAM中的具体布局。
IAR EWARM：进入“Options” -> “Linker” -> “Config”选项卡。在“Linker configuration file”中，选择LPC865_flash.icf文件。
MCUXpresso：在“Project Properties” -> “C/C++ Build” -> “Settings” -> “Tool Settings” -> “MCU C Linker” -> “General”中，勾选“Use custom linker script file”，并指定LPC865_flash.ld文件。

2.3.2 头文件包含路径

确保编译器能找到所有必要的头文件，包括CoreMark的头文件、NXP SDK的驱动头文件以及移植层头文件。在各自IDE的编译器设置中，添加对应的包含路径（Include Paths）。通常需要添加SDK的drivers、device、component等目录，以及我们存放coremark.h和core_portme.h的source和port_lpc860目录。

2.3.3 优化等级的双重配置策略

这是CoreMark测试中最容易出错，也最需要理解的一点：性能测试和功耗测试需要不同的编译器优化等级。

CoreMark性能测试（-O3）：目标是获得最高的性能分数。我们需要启用编译器最高级别的速度优化（如GCC/ARMCC的-O3）。优化器会 aggressively 地进行内联、循环展开、指令重排等操作，以生成最高效的机器码。这代表了MCU在极致优化下的性能上限。
功耗测试（-O0）：目标是测量MCU执行“典型代码”时的功耗。如果使用-O3，编译器可能会将整个循环或函数调用优化掉，导致CPU实际执行的动作与源代码逻辑严重不符，测得的功耗不能代表真实应用场景。因此，必须将优化等级设置为无优化（-O0），确保生成的指令与C代码逻辑基本一一对应，这样测得的动态电流才具有参考价值。

在IDE中如何设置？

Keil MDK： “Options for Target” -> “C/C++ (AC6)” -> “Optimization” 下拉框选择-O3(性能测试) 或-O0(功耗测试)。
IAR EWARM： “Options” -> “C/C++ Compiler” -> “Optimizations” -> “Level” 选择High(性能测试) 或None(功耗测试)。选择High时，最好再勾选“Speed”和“No size constraints”。
MCUXpresso： “Project Properties” -> “C/C++ Build” -> “Settings” -> “Tool Settings” -> “MCU C Compiler” -> “Optimization” -> “Optimization Level” 选择Optimize most (-O3)或None (-O0)。

2.3.4 创建多构建配置提升效率

手动来回切换优化等级既麻烦又容易出错。现代IDE都支持多构建配置（Build Configuration）。我们可以创建两个配置：

CoreMark_Perf：优化等级-O3，用于性能测试。
Power_Meas：优化等级-O0，用于功耗测试。

在Keil MDK中，可以通过工具栏的“目标选择”下拉框旁的管理按钮来创建和管理配置。在IAR中，通过“Project” -> “Edit Configurations”操作。在MCUXpresso中，通过“Project” -> “Build Configurations” -> “Manage...”来操作。创建好后，只需切换激活的配置并重新编译，即可快速在两种测试模式间切换，大大提升了测试流程的效率和可靠性。

3. 硬件准备与功耗测量电路剖析

纸上得来终觉浅，绝知此事要躬行。工程编译通过只是第一步，真实的测试数据需要在实际的硬件上获取。我们使用NXP官方的LPCXpresso860-MAX开发板作为测试平台。这块板子集成了LPC865M201芯片、调试器（CMSIS-DAP）、电源电路和基本外设，开箱即用。

3.1 开发板认知与关键接口

拿到板子，首先认识几个关键部分：

核心MCU： LPC865M201，这就是我们测试的对象。
调试/供电接口（J4）：这是一个USB Type-C接口，它同时提供板载调试器（CMSIS-DAP）的通信和整个板子的5V电源。通过一根USB线连接电脑，即可完成供电、程序下载和调试。
串口终端：板载调试器通常还集成了一个USB转串口（UART）功能，用于打印程序输出。在电脑设备管理器中，会识别出一个额外的COM口。
功耗测量点（JP2）：这是本次测试的“关键观测窗口”。板子上有一个跳线帽JP2，它串联在MCU核心电源的路径上。通过测量JP2两端的电压差（实际是电流在采样电阻上的压降），我们可以计算出流入MCU的电流。

3.2 精确功耗测量的硬件改造

为了测量MCU自身的功耗，我们需要尽可能排除板上其他元器件的耗电干扰。根据应用笔记指导，需要进行以下操作：

移除LED：开发板上的用户LED（D1， D2， D3等）在默认情况下可能被GPIO驱动点亮。即使程序将其关闭，其内部电路也可能存在微小的漏电流。为了获得最纯净的MCU功耗，最好将这些LED的焊盘用电烙铁和吸锡器移除。这是一个精细活，需要小心避免损坏焊盘。如果条件不允许，至少要在软件初始化时，将这些LED对应的GPIO引脚配置为高阻输入模式，并关闭内部上拉/下拉电阻，以最小化影响。
断开功耗测量跳线：找到板上的电阻R51（或类似标识的0欧姆电阻），它可能并联在JP2两端。用热风枪或烙铁将其移除。这样，JP2就成为了MCU核心供电回路上的唯一通道。
连接万用表：将数字万用表（DMM）调至直流电流档（mA或μA档，根据预估电流选择合适量程）。断开JP2上的跳线帽，将万用表的红黑表笔分别连接到JP2的两排插针上，构成一个串联测量电路。

注意事项：这是一个非常关键的步骤。错误的连接（如并联）可能会短路电源，烧毁板卡或万用表保险丝。务必确认万用表已切换到电流测量模式，并且串联在电路中。测量完成后，必须将跳线帽插回JP2，否则MCU将无法上电工作。

3.3 调试终端配置与通信验证

测试结果需要通过串口打印出来，我们需要一个串口终端软件。Putty、Tera Term、SecureCRT或者国内常用的SSCOM、XCOM都可以。以Tera Term为例：

用USB线连接板子J4口和电脑。
打开电脑设备管理器，在“端口（COM和LPT）”下找到新出现的串口，记下COM编号（如COM5）。
打开Tera Term，选择“Serial”，端口选择对应的COM5。
设置串口参数：波特率9600，数据位8，停止位1，校验位无，流控制无。这些参数必须与代码中UART初始化的设置完全一致。
连接后，给板子复位，你应该能看到程序启动后打印的菜单信息。如果看不到，请检查：USB线是否接好、串口号是否正确、波特率是否匹配、代码中串口初始化是否成功。

4. 测试执行流程与数据采集实战

一切准备就绪，现在可以开始运行测试并采集数据了。这个过程需要我们在性能测试和功耗测试两种模式下交叉进行，并记录不同频率下的结果。

4.1 CoreMark性能测试执行步骤

编译与下载：在IDE中，切换到CoreMark_Perf(优化等级-O3) 配置，编译整个工程。确保没有错误和警告。然后通过调试器将程序下载到LPC86x的Flash中。
连接终端：打开配置好的串口终端软件。

运行测试：按下板上的复位按钮。终端会显示一个选择菜单，通常类似：

======================================== LPC86x CoreMark & Power Measurement Test ======================================== 1. CoreMark Test 2. Active Power Consumption Test Please select:

通过键盘输入1，选择CoreMark测试。

选择频率：随后，程序会列出LPC86x支持的各种时钟源和频率选项，例如：
```
Select Core Clock: 1. 18 MHz (FRO) 2. 24 MHz (FRO) 3. 30 MHz (FRO) 4. 36 MHz (FRO) 5. 48 MHz (FRO) 6. 60 MHz (FRO)
```
输入对应的数字（如6）选择60MHz频率。选择后，程序会显示当前的系统配置（时钟源、Flash加速器设置等），然后开始执行CoreMark算法。
获取结果： CoreMark算法会运行一段时间（通常几十秒）。完成后，终端会打印出详细结果，其格式遵循EEMBC规范，核心信息如下：
```
2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 20000 Total time (secs): 10.000000 Iterations/Sec : 92.710000 Iterations : 927 CoreMark 1.0 : 92.710000 / ARMCC5.06 update 6 -O3 -Otime / STACK
```
这里Iterations/Sec就是最终的CoreMark分数，本例中为92.71。同时，我们还需要记录下测试时配置的Flash访问等待周期（Flash Access Time）和缓存（Cache）是否启用，这些信息也会在系统配置中打印出来，对分数有显著影响。

4.2 动态功耗测试执行步骤

功耗测试的流程与性能测试类似，但关键区别在于编译器优化等级和需要连接万用表。

切换配置：在IDE中，切换到Power_Meas(优化等级-O0) 配置，重新编译并下载程序。
连接万用表：确保已按照3.2节所述，将万用表正确串联在JP2上，并选择适当的电流量程（建议先从10mA档开始）。
运行测试：复位板子，在终端菜单中选择2（Active Power Consumption Test）。
选择频率与读取电流：同样选择要测试的核心频率（例如1 MHz LPOSC, 18 MHz FRO等）。在程序开始执行特定的功耗测试循环（通常是一个空循环或简单计算循环）后，万用表显示的电流读数会趋于稳定。记录下这个稳定的电流值（单位mA）。这就是该频率下，MCU核心运行典型代码时的动态工作电流。
计算能效指标：除了记录绝对电流值，我们通常更关心能效比，即每兆赫兹的电流消耗（μA/MHz）。计算公式为：电流(mA) * 1000 / 频率(MHz)。例如，在18MHz下测得电流为4.14mA，则能效为4.14 * 1000 / 18 ≈ 230.00 μA/MHz。这个值越低，说明MCU的能效越高。

4.3 测试组合与数据记录表

为了全面评估，我们需要测试不同核心频率下的CoreMark分数和功耗。应用笔记中给出了一个完整的测试矩阵。这里我将其整理并补充说明，形成我们自己的测试记录表。测试时，应严格按照“性能测试（-O3）”和“功耗测试（-O0）”分别进行，并记录以下信息：

测试模式	核心频率 (MHz)	Flash配置 (等待周期/缓存)	IDE (优化等级)	CoreMark 分数	功耗 (mA)	μA/MHz	CoreMark/mA (能效比)
性能测试	60	3周期，缓存开	IAR EWARM (-O3)	92.71	(不测)	(不测)	(不测)
性能测试	60	3周期，缓存开	Keil MDK (-O3)	80.21	(不测)	(不测)	(不测)
性能测试	60	3周期，缓存开	MCUXpresso (-O3)	82.78	(不测)	(不测)	(不测)
功耗测试	60	3周期，缓存开	IAR EWARM (-O0)	(不测)	10.12	168.67	9.16
功耗测试	18	1周期，缓存开	IAR EWARM (-O0)	(不测)	4.14	230.00	(需结合性能分计算)
性能测试	18	1周期，缓存开	IAR EWARM (-O3)	43.86	(不测)	(不测)	10.59

表格解读与实操技巧：

Flash配置： LPC86x的Flash存储器访问速度可能跟不上CPU核心速度，因此需要插入等待周期。频率越高，所需的等待周期数可能越多（如18MHz用1周期，60MHz用3周期）。启用Flash加速器或缓存可以大幅提升性能，但可能会轻微增加功耗。测试时需要记录这些设置。
交叉分析：上表中最后一行我计算了一个衍生指标CoreMark/mA，即每毫安电流能换取的CoreMark性能。这个值（10.59）比60MHz下的9.16还要高！这揭示了一个重要现象：最高性能点未必是最佳能效点。对于电池供电设备，在18MHz下工作，虽然绝对性能（43.86）只有60MHz下（92.71）的一半不到，但能效却更高。这为我们的产品选型和工作点配置提供了关键依据。
数据记录：我强烈建议使用Excel或Google Sheets来实时记录数据，并利用公式自动计算μA/MHz和CoreMark/mA。这能让你在测试过程中快速发现异常值或趋势。

5. 测试结果深度分析与工程启示

拿到一大堆测试数据后，如何解读它们并指导实际开发？我们结合应用笔记中的数据和我个人的测试经验，进行深度分析。

5.1 CoreMark性能结果分析

从提供的测试数据（表1-表7）中，我们可以总结出影响LPC86x CoreMark分数的几个关键因素：

核心频率：这是最直接的因素。在相同Flash配置下，频率越高，CoreMark分数基本呈线性增长。例如在IAR EWARM、Flash缓存开启的情况下，从18MHz到60MHz，分数从43.86增长到92.71。
编译器优化与IDE差异：同一硬件，不同编译器产生的代码效率不同。数据显示，IAR EWARM的优化效果最好，在多数频率下都取得了最高的CoreMark分数，其次是MCUXpresso（GCC编译器），Keil MDK（ARMCC/AC6编译器）略低。这提醒我们，在追求极致性能时，编译器的选择也是一个考量因素。
Flash存储器子系统：这是Cortex-M0+这类使用Flash作为指令存储器的MCU的性能瓶颈所在。数据清晰表明：
- 启用Flash缓存（Cache）和预取缓冲区（Buffer）对性能提升巨大。对比表6和表7（60MHz， IAR），启用缓存后分数从78.04提升到92.71，提升幅度接近19%。在项目开发中，只要Flash空间允许，务必在系统初始化时使能这些加速功能。
- Flash访问等待周期：频率升高后，需要增加等待周期（如从1-access到3-access）来保证稳定读取，但这会引入性能损失。这是硬件限制，需要在时钟初始化时根据频率正确配置。

5.2 动态功耗结果分析

功耗数据（表8-表14）则揭示了另一面：

绝对功耗随频率升高而增加：这是显而易见的，从1MHz LPOSC的约0.36mA到60MHz FRO的约8.82mA（IAR）。
能效（μA/MHz）随频率升高而降低：这是一个非常积极的信号。计算μA/MHz可以发现，60MHz下（~168 μA/MHz）的能效比1MHz下（~360 μA/MHz）要好得多。这意味着对于相同的计算任务，在更高频率下快速完成然后进入睡眠模式，可能比在低频率下长时间运行更省电。这是低功耗设计中的经典策略：Race to Sleep。
编译器优化对功耗的影响：功耗测试是在-O0（无优化）下进行的，模拟了“普通代码”的功耗。如果我们在-O3下测功耗，电流可能会更低（因为代码执行更快，更快进入空闲），但这不能代表真实应用的代码密度和执行模式。因此，功耗测试坚持用-O0是合理的。

5.3 综合能效评估与选型建议

将性能和功耗数据结合起来看，我们可以绘制出“性能-功耗”曲线，并计算不同工作点的“能效比”（CoreMark/mA或CoreMark/mW）。以IAR EWARM的数据为例（假设电压为3.3V，功率P=U*I）：

频率 (MHz)	CoreMark	电流 (mA)	功率 (mW)	CoreMark/mW
18	43.86	4.14	13.66	3.21
24	58.48	5.39	17.79	3.29
30	59.30	6.06	20.00	2.97
36	71.17	7.09	23.40	3.04
48	73.92	8.21	27.09	2.73
60	92.71	10.12	33.40	2.78

从这个简化分析可以看出，24MHz附近可能是一个能效的“甜点区”，在性能和功耗之间取得了很好的平衡。当然，实际选型还需要考虑：

任务负载特性：如果你的应用是突发性工作（如传感器采样后无线发送），那么高频（60MHz）快速处理然后深度睡眠是最佳策略。
外设需求：某些通信接口（如高速SPI）可能需要较高的核心时钟。
成本与开发便利性：有时，选择中间频率可以降低对PCB布线和电源完整性的要求。

5.4 常见问题与排查技巧实录

在实际操作中，你可能会遇到以下问题：

问题：编译时提示找不到core_portme.h或coremark.h。
- 排查：检查IDE中的包含路径（Include Paths）设置。确保路径指向了存放这些头文件的正确目录。路径中不要有中文或空格。
- 技巧：在core_portme.c开头使用#include “coremark.h”时，使用双引号而非尖括号，并确保该文件在工程源文件目录中。
问题：程序下载后运行，串口无任何输出。
- 排查：
  - 确认板子供电正常，复位按钮是否按下。
  - 确认串口终端参数（波特率、数据位等）与代码中uart_init()函数设置完全一致。
  - 检查core_portme.c中的uart_putchar()或printf重定向函数是否正确实现，是否调用了正确的SDK UART发送API。
  - 在main()函数或portable_init()最开始，尝试点亮一个LED或执行一个简单的GPIO翻转，用示波器查看，以确认程序是否真的在运行。
- 技巧：在串口初始化前，先配置一个GPIO引脚驱动LED闪烁，作为“心跳”指示，这是调试裸机程序最基本有效的手段。
问题：CoreMark分数与官方或他人测试结果差异巨大。
- 排查：
  - 首要检查优化等级：确认性能测试时是否为-O3（或IAR的High Speed）。
  - 检查系统时钟：确认代码中系统时钟（SystemCoreClock）是否正确配置到了目标频率（如60MHz）。可以在代码中打印SystemCoreClock变量的值来验证。
  - 检查Flash加速配置：确认Flash访问等待周期（FLASHCFG寄存器）和缓存是否根据当前频率正确启用。这是影响分数最关键的因素之一。
  - 检查编译器版本：不同版本的编译器优化能力可能有差异。记录下你使用的IDE和编译器具体版本号。
问题：万用表测得的电流值不稳定或为0。
- 排查：
  - 确认万用表串联正确且档位合适：电流档位太小会超量程，太大会精度不足。先从较大档位（如10mA）开始，再逐步调小。
  - 确认JP2跳线帽已移除：如果跳线帽还在，电流会走跳线帽短路，万用表显示为0或极小值。
  - 确认测试代码在运行：功耗测试代码应该是一个不会停止的循环。如果程序跑飞或进入休眠，电流会骤降。可以通过在循环中增加一个GPIO翻转，用示波器观察该引脚波形，来确认CPU是否在持续运行。
  - 排除板载其他器件影响：再次确认已移除LED或将其GPIO设置为高阻输入。检查是否有其他外设（如调试器部分）在测试时仍在工作，可以尝试仅给MCU部分供电（如果板子支持）进行更精确的测量。