引言
什么是MicroLIB
不使用Microlib导致卡死的原理
卡死解决办法：
优化空间测评
先说问题，这几天在使用STM32H750调试程序的过程中出现了一些问题，博主使用下载用CubeMX初始化好的程序后，程序不执行，表现为以下几个状态：
看到这里的朋友不知道能不能猜出问题在哪，综上所述已经能完全排除芯片问题，下载器问题，经过长时间的工程文件对比后，发现了一个极不起眼的小问题；
Use MicroLIB没有被勾选，然后勾上程序就TM运行了。
问题是解决了，但是不能这么死的不明不白，于是深入了解并学习一下MicroLIB。
来自ARM-MDK官网的解释：
MicroLib 是一个高度优化的库，适用于用 C 编写的基于 ARM 的嵌入式应用程序。与 ARM 编译器工具链中包含的标准 C 库相比，MicroLib 提供了许多嵌入式系统所需的显着代码大小优势。
MicroLib 和标准 C 库之间的主要区别是：
详细参考网址：https://www.keil.com/arm/microlib.asp
说这么多也没有什么实质作用，网上大多数资料也没有说到点子上，我结合实际开发总结一下真正跟咱们有关系：
在使用CubeMX初始化代码时，生成的工程默认是使用Microlib的，正常情况下，在STM32CubeMX通过成的.s文件里可以看到一个__main函数，这个就是microlib的入口地址，他会完成创建栈空间，创建堆空间，初始化用户可能用到的系统库等初始化动作，最后跳转到我们熟悉的main，当使用Microlib时，__main链接的是Microlib，当不使用Microlib时，__main链接的是标准库的C/C++；
至此，还并没有出现什么问题，但是，一旦在程序中调用printf等函数时，会让MCU进入半主机模式，进而程序会在__main位置卡死，这也就是为什么程序正常编译正常烧录正常调试，但是运行不起来而且Debug卡死在__main位置的原因。
使用C标准库(stdio.h)中的函数，例如printf()之类的函数，会进入半主机模式，发生软件异常，会导致程序无法运行。半主机是这么一种机制，它使得在ARM目标上跑的代码，如果主机电脑运行了调试器，那么该代码可以使用该主机电脑的输入输出设备。 这点非常重要，因为开发初期，可能开发者根本不知道该 ARM 器件上有什么输入输出设备，而半主基机制使得你不用知道ARM器件的外设，利用主机电脑的外设就可以实现输入输出调试。 所以要利用目标 ARM器件的输入输出设备，首先要关掉半主机机制。然后再将输入输出重定向到 ARM 器件上。
解决办法有两种，要么使用Microlib，要么关闭标准库下的半主机模式。
个人认为，后者更加好一点，原因如下：
关闭半主机模式的操作方式：
将以下代码添加到文件起始处；
/* 告知连接器不从C库链接使用半主机的函数 */
#pragma import(__use_no_semihosting)
/* 定义 _sys_exit() 以避免使用半主机模式 */
void _sys_exit(int x)
{
x = x;
}
/* 标准库需要的支持类型 */
struct __FILE
{
int handle;
};
FILE __stdout;之后放心大胆的重定向printf即可使用。
同一个程序不使用Microlib：
同一个程序使用Microlib：
可见，并没有什么优化大小