在基于STM32开发一个项目过程中，遇到一个比较奇葩的现象：经常会时不时出现修改上层的应用代码导致程序运行不起来，进不去main函数。这个STM32程序是分为bootloader层和APP层，出现这个奇葩现象的时候，bootloader层是可以正常运行的，但是跳转到APP层的时候，就发现进不了main函数。

   一开始也是找不到原因何在，通过网上搜索发现也有类似出现STM32进不去main函数的，原因多数是因为printf函数的应用导致的。但通过代码检查发现我遇到的这个奇葩现象，并非printf函数运用导致。这里也借此了解一下printf函数在stm32中使用注意事项，避免出现这个错误。

printf函数：

  printf之类的函数，使用了半主机模式，所以要利用目标ARM器件的输入输出设备，首先要关掉半主机机制，然后再将输入输出重定向到ARM器件上，如printf和scanf，需重写fputc和fgetc.

具体代码实现可参考如下（重写fputc）：

如果不重写fputc等函数，也可直接勾选keil工具里面的Use MicroLIB.

    当经过检查后，发现并非是printf函数使用不当导致程序进不去main函数，于是采用在线仿真的方式一步步查找原因。

第一步：先是全速运行，发现程序直接进入了HardFault_Handler。

接着分析启动文件startup_stm32xx.s：在执行进main函数之前，会先执行SystemInit函数，进行系统初始化。

在SystemInit函数里面打断点，单步执行调试，看程序能否执行进来：发现程序可以执行进来。

于是结合上面分析的printf函数原因， 于是尝试在fputc函数打一断点，看是否会跑进fputc函数：发现程序确实跑进了fputc函数

  通过SystemInit函数单步执行跑到fputc函数可以分析到，应该是程序哪里出错后，执行了打印输出，而此时串口并未初始化。发现从SystemInit到fputc这样顺序执行下来，不可能会出现打印的函数，那此时有可能就是发生了某种中断，导致在进入main函数之前，跑进了一个中断处理函数里面去了。

 那有可能是哪个中断导致的呢？： 像定时器、RTC这些中断，都是进入main函数初始化后才会开启的，排除了这类中断，那应该就是某种系统中断导致的。该stm32程序用到了FreeRtos系统，那可能中断就是systick中断，svc中断，pendsv中断。而svc、pendsv中断都是FreeRtos系统启动后才会执行的。那最大可能就是systick中断了。

接着在systick中断函数打断点，重新单步执行，看是否进入该中断：确实进入了该中断。

通过对这个中断函数一步步执行，发现最终在此处出错了：进入了HardFault_Handler。

定位到是系统滴答中断systick导致进不去main函数的原因了，那哪里开启了这个中断呢？通过代码分析发现是bootloader程序开启了这个中断，在跳转到main函数之前并未关闭这个中断，导致出现了这中异常错误。

  既然是系统滴答中断导致的进不去main函数，那就要在进入main函数之前关闭这个滴答中断。

方法一： 在bootloader程序跳转到app层时就关闭系统滴答中断：SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk;

方法二：在SystemInit函数关闭系统滴答中断：SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk; （如下图所示）

  在实际项目运用过程中，遇到类似这些奇葩现象，可以尝试通过仿真调试，一步步尝试可能出现错误的地方，进行打断点分析，找出根因所在，你的点赞是我最大的动力。