最近在做嵌入式课设，选用的是STM32F103系列单片机——相信这是每一位嵌入式入门大学生最熟悉的芯片了。作为ST公司推出的入门级32位微控制器，STM32F103凭借性价比高、资源适中、资料丰富的优势，成为高校嵌入式课程、课设以及竞赛的首选芯片，我们实验室几乎人手一块基于这款芯片的开发板。

简单给大家介绍一下这款芯片：STM32F103属于Cortex-M3内核，主频最高可达72MHz，我使用的STM32F103C8T6型号，Flash容量为128KB，SRAM容量为20KB，支持多种外设接口，比如UART、SPI、I2C、ADC等，足以满足我们课设中常见的显示驱动、按键控制、简单游戏逻辑实现等需求。这次我的课设是在智能手表开发板上实现谷歌小恐龙游戏，用到了这款最常用的STM32型号，本来已经完成了游戏的核心逻辑编写，结果突然遇到了一个超级诡异的烧录问题，折腾了我整整两天，差点影响课设进度。今天终于解决了，而且解决方案完全颠覆了我之前的认知，必须写下来给大家避坑。

问题描述

事情是这样的，我写好谷歌小恐龙游戏的代码之后，编译一点问题都没有，0错误0警告——代码里包含了小恐龙的跳跃逻辑、障碍物生成、分数统计以及手表屏幕显示驱动等功能，本来以为能顺利烧录到智能手表开发板上测试，但是一点下载按钮，等个几秒钟就弹出错误，控制台输出：

 

Flash Timeout. Reset the Target and try it again. Error: Reset Cortex-M3 (error -1) Flash Download failed - Target DLL has been cancelled

一开始我以为是小问题，毕竟烧录失败在STM32开发中太常见了，尤其是我们这种刚接触嵌入式的大学生，接线松动、配置失误都是常有的事。结果没想到，这才是我两天踩坑之路的开始，我把能试的方法都试了个遍，却始终没能解决问题，游戏代码一直无法烧录到智能手表开发板上。

我踩过的所有常规坑

面对这个报错，我第一时间去网上搜了解决方案，发现大部分教程都集中在硬件接线、下载器配置这些常规问题上，我按照教程一步步排查，你们能想到的方法我基本都试过了，每一步都仔细核对，却还是没效果：

1. 检查接线：STM32F103的SWD下载只需要4根线——SWDIO、SWCLK、GND和3.3V，我用的智能手表开发板集成了STM32芯片，我把下载线拔了又插，换了三组不同的杜邦线，反复确认SWDIO和SWCLK没有接反，GND也绝对接牢了，毕竟GND接触不良是导致通信失败的最常见原因，可排查后问题依旧。

2. 降低下载时钟：我使用的是ST-Link下载器，一开始下载时钟设置的是10MHz，我按照教程一路降到400kHz，甚至试了100kHz，想着降低速率能减少通信干扰，避免因游戏代码包含屏幕驱动逻辑、多任务调度，导致下载时通信不稳定，可不管怎么调，还是会报Flash Timeout错误。

3. 按住复位键下载：这个方法是网上公认的“急救方案”，很多人说按住开发板的RESET键，点击下载后再松开，就能解决芯片卡死导致的下载失败。我试了几十次，偶尔能成功一次，但成功烧录后，运行游戏时会出现屏幕花屏、按键无响应的问题，重新编译再下载，又会回到报错状态。

4. 检查BOOT引脚：STM32F103的启动模式由BOOT0和BOOT1两个引脚的电平决定，正常烧录和运行需要设置为“主Flash启动”，也就是BOOT0接GND、BOOT1接GND。我反复确认了智能手表开发板上的BOOT引脚接线，没有接错，甚至重新插拔了BOOT引脚的杜邦线，还是没用。

5. 解除芯片保护：我怀疑是芯片开启了读保护，导致无法擦写Flash，于是用ST-Link Utility软件擦除了全片，解除了读保护，重新烧录游戏代码后，报错依然没有消失。要知道，STM32的Flash保护功能是为了防止程序被篡改，一旦开启确实会导致烧录失败，但这次显然不是这个原因。

6. 更换下载器和硬件：我找同学借了DAP-Link下载器，和我的ST-Link换着试，结果报错一模一样；又借了一块同款智能手表开发板，把我的谷歌小恐龙游戏代码烧进去，居然也报同样的Flash Timeout错误。这时候我才意识到，这绝对不是硬件问题，也不是下载器的问题，肯定是软件或者配置哪里出了问题。

7. 检查工程配置：我重新检查了Keil的工程配置，确认芯片型号选择的是STM32F103C8T6，Flash容量设置为128KB（和我所用芯片的实际容量一致），时钟配置也没问题，没有出现外部晶振未接却配置HSE时钟的错误——要知道，若未正确处理HSE超时逻辑，也可能导致芯片卡死，而我的游戏代码需要稳定的时钟来驱动屏幕刷新和游戏逻辑，时钟异常会影响很多功能，但我排查后确认时钟配置无误，可问题还是没有解决。

折腾到这里，我真的有点崩溃了，课设 deadlines越来越近，谷歌小恐龙游戏的核心逻辑都已经写好了，却连烧录都烧不进去，我甚至怀疑是游戏代码有隐藏错误，虽然编译没报错，但可能是屏幕驱动、按键中断的逻辑冲突，导致芯片跑飞。于是我新建了一个空白工程，只写了简单的手表屏幕点亮、按键检测代码，编译后下载，居然还是报同样的Flash Timeout错误！这一下，我彻底懵了，空白工程都能报错，到底是哪里出了问题？

偶然发现的神奇解决方案

就在我准备放弃，打算重新安装Keil软件，甚至换一台电脑试试的时候，我随手点开了Keil的“魔法棒”（Options for Target）设置，在Target选项卡里，看到了那个我从来没碰过的“Use MicroLIB”选项。

我之前听老师讲过，MicroLIB是Keil MDK专门为嵌入式系统优化设计的精简版C标准库，和我们平时默认使用的标准C库相比，它的体积更小，占用的Flash和SRAM资源更少，但功能也相对简单，一些标准C库的函数它并不支持，老师当时还提醒我们，没有特殊需求不要随便勾选，以免出现功能异常。后来我查阅资料才知道，MicroLIB是ARM架构嵌入式开发中常用的轻量级库，早在Keil MDK v3.1及以上版本就已包含，核心用于资源受限的MCU开发，尤其适合智能手表这类小型嵌入式设备。

但当时实在是没辙了，死马当活马医，我就随手勾了一下“Use MicroLIB”，然后点击OK保存设置，重新编译谷歌小恐龙游戏工程，再点击下载按钮——没想到，几秒钟后，下载成功的提示弹了出来，手表屏幕正常点亮，游戏也能正常运行，小恐龙跳跃、障碍物生成、分数统计等功能都没有异常！

我当时人都傻了，反复试了好几次，只要勾上Use MicroLIB，下载就100%成功，游戏运行也完全正常；只要取消勾选，立刻又报Flash Timeout和Reset Cortex-M3的错误。这个反常识的解决方案，真的让我又惊又喜，困扰我两天的问题，居然就这么轻易解决了。这里也提醒大家，仅勾选Use MicroLIB选项并不代表一定生效，可通过添加验证代码或查看编译日志中“using microlib”关键字，确认MicroLIB是否真正启用，避免因未生效导致游戏代码依然无法烧录。

为什么会这样？（结合STM32芯片特性解读）

解决问题后，我查了很多资料，结合STM32F103的芯片特性，终于搞明白了这个诡异现象的原理，其实和我们所用芯片的Flash、SRAM资源，以及谷歌小恐龙游戏代码的特性、C库的初始化机制有关。

我们平时用Keil编译STM32程序时，默认使用的是标准C库（Standard Library）。这款库功能完善，但体积较大，而且在程序进入我们写的main函数之前，会执行一段很长的初始化代码。这段代码会做很多事情：初始化全局变量和静态变量、分配堆和栈空间、初始化C库的各种功能模块，还会默认启用半主机模式——这是ARM特有的调试辅助机制，会让单片机程序“借用”PC端资源完成输出等操作，最后才会跳转到main函数执行我们自己的游戏代码。

而我们使用的STM32F103C8T6，虽然有128KB的Flash和20KB的SRAM，对于谷歌小恐龙游戏这类课设项目来说足够用，但我的游戏代码包含了屏幕驱动、按键中断、游戏逻辑调度等内容，再加上标准C库的初始化代码，占用的资源并不少，而且标准C库的初始化时间相对较长。更关键的是，Keil的烧录器在下载程序时，有一个固定的超时机制——它会在芯片复位后等待一段时间，如果这段时间内芯片没有响应烧录命令，就会认为烧录失败，弹出Flash Timeout错误。

我的情况就是这样：标准C库的初始化时间，加上游戏代码中全局变量（如游戏状态、分数、障碍物坐标等）的初始化，总耗时超过了烧录器的超时时间。芯片其实没有坏，也没有跑飞，只是还在执行初始化代码（包括半主机模式的初始化），还没来得及响应烧录器的命令，烧录器就已经超时断开连接了，所以才会报Flash Timeout和Reset Cortex-M3的错误。值得注意的是，若代码中使用printf等函数打印游戏分数、调试信息，但未勾选MicroLIB，即使烧录成功，脱机运行时也可能因半主机模式卡死，导致游戏无法正常运行，这也是标准C库的常见“陷阱”。

而MicroLIB作为精简版的C库，正好解决了这个问题。它对标准C库进行了大幅度的精简，去掉了很多嵌入式系统用不到的功能，初始化代码极其简短，执行速度极快，几乎是芯片一复位，就能完成初始化，进入可以响应烧录命令的状态。而且MicroLIB占用的Flash和SRAM资源更少（比标准C库体积小30%-50%），对于我们128KB Flash的STM32F103C8T6来说，负担更小，启动也更流畅，同时它默认禁用半主机模式，减少了不必要的初始化开销，烧录器自然就能正常和芯片通信，不会再报超时错误。更重要的是，我的谷歌小恐龙游戏用到的都是基础C语言函数，不需要复杂的标准C库功能，MicroLIB完全能满足需求。

两种解决方案（适配STM32F103，亲测有效）

方法一：直接使用MicroLIB（推荐，最简单高效）

这是我亲测最有效的解决方案，操作简单，不需要修改游戏代码，适合我们做课设、小项目的大学生，尤其适合智能手表谷歌小恐龙这类基础嵌入式游戏开发，具体步骤如下：

1. 打开Keil工程，点击工具栏上的“魔法棒”图标，打开Options for Target对话框；

2. 切换到Target选项卡，找到“Use MicroLIB”选项，勾选前面的方框；这里需要注意，若该选项灰色不可选，可能是CPU类型未正确设置或工程启用了C++特性，需先排查这些问题；

3. 点击OK保存设置，然后重新编译工程（Ctrl+F7）；

4. 点击下载按钮（Load），等待几秒，就能成功下载程序，智能手表上的谷歌小恐龙游戏也能正常运行。

 

这里有一个小提醒：如果你的谷歌小恐龙游戏需要使用printf函数打印分数、调试信息，或者通过串口传输游戏数据，勾选Use MicroLIB后，需要自己重定向printf函数，并且添加禁止半主机模式的代码，否则会出现报错，代码如下（适配STM32F103，基于HAL库，可直接复制使用）：

#pragma import(__use_no_semihosting) struct __FILE { int handle; }; FILE __stdout; FILE __stdin; // 避免半主机模式报错 void _sys_exit(int x) { x = x; // 空操作，防止编译器报错 } // printf函数重定向到串口1，可用于打印游戏分数、调试信息 int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 100); // huart1可根据自己的串口配置修改 return ch; }

对于谷歌小恐龙游戏这类课设项目来说，MicroLIB完全够用，而且它体积小、启动快，还能节省STM32的Flash和SRAM资源，避免因游戏代码+标准C库占用过多资源，导致游戏运行卡顿，非常适合我们这种入门级嵌入式游戏开发。但这里必须重点提醒大家：使用MicroLIB可能会导致部分功能发生改变，甚至出现异常，这也是老师不建议我们随便勾选的核心原因，大家一定要根据自己的课设需求（尤其是游戏功能需求）谨慎选择。

具体来说，MicroLIB的功能精简会带来这些潜在问题，尤其适合我们做智能手表游戏课设时避坑：第一，部分标准C库函数不支持，比如一些复杂的字符串处理函数、浮点运算相关的高级函数——MicroLIB默认不支持printf函数的浮点数格式输出（如%f、%g），若你的游戏需要显示小数分数、浮点型参数，需额外配置浮点库，这会增加代码体积，违背其精简初衷；同时它不支持文件I/O（如fopen、fclose）和宽字符函数（如wprintf），若课设中需要实现游戏存档、读取存档功能，勾选MicroLIB后会出现编译报错，或者运行时功能异常。第二，中断处理机制略有不同，MicroLIB对中断的支持不够完善，谷歌小恐龙游戏需要用到按键中断实现小恐龙跳跃，若中断较多，可能会出现中断响应不及时、跳跃不灵敏的情况。第三，和部分第三方库兼容性较差，若你的游戏需要调用外部驱动库（比如智能手表的屏幕驱动库、触摸驱动库），这些库可能是基于标准C库编写的，使用MicroLIB后可能会出现无法正常调用、屏幕花屏、触摸失灵的问题，尤其是部分简单RTOS若使用了malloc/free，需确认其内存管理机制与MicroLIB兼容。第四，MicroLIB的malloc和free实现简单，不支持内存碎片整理，若游戏中频繁生成、销毁障碍物（动态分配内存），可能导致内存碎片问题，影响游戏稳定性，出现卡顿、闪退的情况。

所以大家在勾选Use MicroLIB之前，一定要先确认自己的谷歌小恐龙游戏需求：如果只是实现基础的跳跃、障碍物生成、分数统计、屏幕显示功能，MicroLIB完全可以满足，且能解决Flash Timeout的问题；但如果游戏中用到了复杂的函数、较多中断、第三方驱动库或频繁的动态内存分配（如大量障碍物随机生成），建议优先选择方法二优化标准C库，避免因MicroLIB导致游戏功能异常，影响课设进度。

方法二：优化标准C库的初始化（不使用MicroLIB）

如果你因为某些原因必须使用标准C库，比如你的谷歌小恐龙游戏需要使用MicroLIB不支持的函数（如复杂的字符串处理、游戏存档功能、浮点型分数显示），可以尝试以下方法优化初始化过程，解决烧录超时问题，适配我们128KB Flash的STM32F103：

1. 增加堆栈大小：在Target选项卡中，将Stack Size（栈大小）增加到0x800，Heap Size（堆大小）增加到0x400，避免因堆栈不足导致初始化失败——MicroLIB默认堆较小，而标准C库初始化对堆栈要求更高，游戏代码中大量的全局变量、数组（如障碍物坐标数组、分数存储数组）也需要更多堆栈空间，合理调整堆栈大小能有效减少初始化异常；

2. 减少全局变量的数量：尽量把不必要的全局变量（如临时的游戏状态变量、局部计算变量）改成局部变量，减少标准C库初始化时的工作量，缩短初始化时间；比如将障碍物的临时坐标变量，改为在生成障碍物的函数内部定义，避免全局变量过多增加初始化负担；

3. 优化启动文件：STM32的启动文件（如startup_stm32f103xb.s）中有一些初始化步骤，我们可以去掉一些不必要的初始化（比如不需要使用的外设初始化），但这种方法需要熟悉启动文件的结构，新手不建议轻易尝试；同时可在SystemInit函数中增加HSE超时后的自动切换逻辑，避免因外部晶振问题导致初始化卡死，确保游戏能稳定启动；

4. 检查Flash占用：如果你的谷歌小恐龙游戏代码较大，加上标准C库后，接近128KB的Flash容量，标准C库的初始化会更加耗时，建议精简代码，删除不必要的功能（如冗余的调试代码、未使用的游戏动画），释放Flash资源；

5. 禁用标准C库的半主机模式：若游戏中使用了printf函数打印分数、调试信息，需禁用半主机模式，避免初始化时因半主机模式占用时间过长，导致烧录超时，具体方法和方法一中的代码一致，添加禁止半主机模式和printf重定向代码即可；

6. 优化游戏代码结构：减少游戏初始化阶段的复杂操作，将部分游戏初始化逻辑（如障碍物生成、屏幕初始化）推迟到main函数执行后，避免在标准C库初始化阶段叠加过多操作，缩短整体初始化时间，让芯片能快速响应烧录器的命令。

总结与反思（写给和我一样的嵌入式新手）

这次踩坑经历，真的让我收获很多。作为一名刚接触STM32的大学生，我这次的课设是智能手表谷歌小恐龙游戏，本来以为写完代码就能顺利烧录测试，却因为Flash Timeout报错折腾了两天，我之前一直觉得，嵌入式开发中，硬件问题比软件问题更常见，遇到烧录失败，第一反应就是查接线、查硬件，却忽略了软件配置这个容易被忽视的点。

而且我之前一直被“Use MicroLIB不要随便用”的说法误导，从来没有尝试过用它来解决问题，没想到它居然能完美解决这个棘手的Flash Timeout错误，还能让我的谷歌小恐龙游戏运行更流畅。这也让我明白，技术没有绝对的“好”与“坏”，标准C库功能完善，但在我们128KB Flash的STM32F103上，加上游戏代码的初始化，可能会因为耗时过长导致烧录失败；MicroLIB虽然功能简单，但胜在轻便、快速，刚好适配我们的课设游戏需求。

另外，通过这次问题，我也对STM32F103芯片的Flash、SRAM资源，以及C库的初始化机制有了更深入的了解，不再是只知道“写代码、编译、下载”的新手。其实很多嵌入式开发中的问题，都和芯片的资源特性、软件配置有关，尤其是我们做嵌入式游戏开发，代码中包含显示、中断、逻辑调度等功能，更要注意资源占用和初始化效率，只有多动手、多尝试、多查资料，才能真正搞懂问题的本质。

希望这篇踩坑日记，能帮到和我遇到同样问题的同学，尤其是做智能手表、嵌入式游戏类课设的小伙伴，少走点弯路，别像我一样折腾两天才解决。如果大家还有其他STM32的课设踩坑经历，或者有更好的解决方案，也欢迎在评论区交流，一起进步、一起完成课设！

二更——————————————————

今天总算搞清楚是怎么回事了，首先可以肯定的是确实是内存flash的不足，因为STM32F103C6T6的flash应该只有20kb，而我那个程序的flash要求得24kb，而开启LIB可以使代码高度优化，才得以运行下去，总的来说是我选错了芯片，STM32F103C8T6足以应对这种情况。