这几天在STM32G473使用IAP升级的时候踩了不少坑

1. app程序在SystemClock_Config中跑飞

bootloade和app程序都是通过CubeMX配置，在bootloade引导之后进入app程序，然而在执行到SystemClock_Config函数的时候失败；

经过debug后发现是SystemClock_Config函数执行到以下代码的时候跑飞了

  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK){Error_Handler();}

程序执行进入到了Error_Handler()，头一次在系统时钟初始化的时候跑飞(暴露了见识的短浅)，通过在网上查询找到了原因，看了大佬的博客才明白，是因为bootloade使用了外部时钟，并且配置了PLL，那么再app程序中再次进行配置的时候就出现了问题，大佬的博客中有对应的解决办法，下面就是链接：

STM32实战项目：HAL_RCC_OscConfig中程序卡死问题解决办法_觉皇嵌入式的博客-CSDN博客

我选择了最简单的方法，那就是bootloade不适用外部时钟，不配置PLL，那么在app程序中就不会在SystemClock_Config中跑飞了。

红色：

 后来发现初始不成功的原因可能是两次时钟初始化的不同，我们可将bootloader和app程序的时钟设置相同，也就是各个参数设置为相同的

​

2. 程序HAL_Delay中卡死

app程序就是一个简答的led灯的闪烁，中间使用HAL_Delay控制亮灭的时间

在程序进入到HAL_Delay中之后就没有出来，查看了HAL_Delay函数的介绍发现其是通过中断实现的，现在在HAL_Delay中出问题极有可能是因为中断的原因，查看中断向量表的地址之后发现没有问题，后想到在bootloade中为了防止中断打断升级，所以通过__disable_irq将中断全部关闭，但是在app程序中没有打开，所以没有中断没有执行。

解决办法：

在main的函数的开头加入开中断的语句

__enable_irq();

3. 通过外部flash模拟的U盘没能被电脑识别

通过bootloade引导的app程序不能被电脑识别，但是修改app程序的下载地址之后就能正常识别。

在main函数中USB_DeviceStart中启动了USB，USB的初始化也没有问题，通过bootloade引导的app程序和直接跑的app程序唯一的区别就是中断向量表的不同，再看打开中断和中断向量表切换的语句顺序，错误顺序

	__enable_irq();SCB->VTOR = FLASH_BASE | 0x20000;

可能是使能的中断是bootloade的中断，但是bootloade中没有配置USB，所以导致U盘没有被识别，将上述语句的顺序调转一下就可以了，正确顺序：

	SCB->VTOR = FLASH_BASE | 0x20000;__enable_irq();

4. 将bin文件拷贝到片内flash中失败

bootloade在将bin文件拷贝到片内flash中失败，拷贝过程中突然就HardFault_Handler了 ，HardFault_Handler产生大概率是堆栈越界了，然后看了启动文件，发现在CubeMX配置的时候没有改堆栈的大小，将堆栈调大后发现成功了。

解决办法：

将堆栈的空间调大

5、APP程序跳转过后串口不能工作

在bootloader跳转到app程序之后，确定app的中断向量表已经偏移到指定的位置，其他的中断也能正常的执行，串口的空闲中断却不能使用。应该是在bootloader和app程序的串口配置的不同，但是在跳转到app程序后对串口的再次初始化并没有将其赋为相对应的值。

解决办法：

将app和bootloader使用到的相同的外设配置为相同的状态

这个真是个大坑，若是注意到这一点就能避开很多的麻烦，若是配置的不同很可能有很多隐藏的问题，并且还不容易找出来问题所在。这都是血和泪的教训。

Red>这个真是个大坑，若是注意到这一点就能避开很多的麻烦，若是配置的不同很可能有很多隐藏的问题，并且还不容易找出来问题所在。这都是血和泪的教训。