背景：最近需要在stm32上实现通过rs485升级固件功能。经过几天搜索和调试，实现了功能。
目标：使用cubeIDE实现stm32F407VGT6，通过RS485升级固件
调试记录：
步骤1. 在keil环境下的rs485升级固件(含源码)：STM32 OTA应用开发——通过串口/RS485实现OTA升级（方式2）_stm32串口升级_柒壹漆的博客-CSDN博客步骤2：讲keil工程移植到cubeIDE：
Keil工程迁移至STM32CubeIDE，Keil转cubeide，超详细图文教程_stm32cubeide导入keil_大家伙好的博客-CSDN博客
步骤3：在cubeIDE中，更改app工程烧录地址：
STM32CubeIDE设置Flash烧录地址和大小(告别Keil魔术棒)_stm32cubeide怎么烧录_0.零点开发的博客-CSDN博客
此步骤需要做出的改动如下，FLASH_BASE无需更改：
改动1：配置flash和ram，在STM32F407VGTX_FLASH.ld
MEMORY
{
CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 100K
FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 992K
}
改动2：配置中断向量， 在Core/Src/system_stm32f4xx.c
#define USER_VECT_TAB_ADDRESS
#if defined(USER_VECT_TAB_ADDRESS)
/*!< Uncomment the following line if you need to relocate your vector Table
in Sram else user remap will be done in Flash. */
/* #define VECT_TAB_SRAM */
#if defined(VECT_TAB_SRAM)
#define VECT_TAB_BASE_ADDRESS SRAM_BASE /*!< Vector Table base address field.
This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET 0x00000000U /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */
#else
#define VECT_TAB_BASE_ADDRESS FLASH_BASE /*!< Vector Table base address field.
This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET 0x00008000U /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */
#endif /* VECT_TAB_SRAM */
#endif /* USER_VECT_TAB_ADDRESS */
步骤4：xshell免费版本下载
xshell7个人免费版官方下载，无需破解，免激活_xshell免费版_Java升级之路的博客-CSDN博客
经过上面几个个步骤，即可将工程建立起来，下面是我调试过程中遇到的问题，解决办法：
问题1：栈顶地址不合规，导致报错
stm32 BootLoader之检查栈顶地址是否合法_eric_pyt@qq.com的博客-CSDN博客
栈顶地址科普见上面，具体解决办法为：将RAM地址大小调小些
问题2：跳转后中断有问题
需要在跳转时候关闭中断，这个问题我没遇见，暂时记录下。
uint8_t jump_app(uint32_t app_addr)
{
uint32_t jump_addr;
jump_callback cb;
__set_PRIMASK(1);
if (((*(__IO uint32_t*)app_addr) & 0x2FFE0000 ) == 0x20000000) {
__ASM("CPSID I");
jump_addr = *(__IO uint32_t*) (app_addr + 4);
cb = (jump_callback)jump_addr;
__set_MSP(*(__IO uint32_t*)app_addr);
cb();
return 1;
}
return 0;
}
问题3：跳转后，程序不运行，卡死
现象1：完全不运行
确认app烧录地址和跳转地址一致，或者程序烧录没问题。
调试方法，可以用仿真器debug查看memory内容，确认目标地址下内容正确
现象2：卡死在delay函数中：
STM32的IAP跳转到APP后卡死在HAL_Delay()延时函数问题分析与解决_ge2ming的博客-CSDN博客
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();
__ASM("CPSIE I"); //
__set_FAULTMASK(0); //
现象3：卡死在SystemClock_Config()
STM32实战项目：HAL_RCC_OscConfig中程序卡死问题解决办法_觉皇嵌入式的博客-CSDN博客
void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};/** Configure the main internal regulator output voltage
*/
__HAL_RCC_PWR_CLK_ENABLE();
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);/** Initializes the RCC Oscillators according to the specified parameters
* in the RCC_OscInitTypeDef structure.
*/
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_SYSCLK;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;
if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)
{
Error_Handler();
}RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 4;
RCC_OscInitStruct.PLL.PLLN = 72;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 4;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}/** Initializes the CPU, AHB and APB buses clocks
*/
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)
{
Error_Handler();
}RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_OFF;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}
}
问题4：卡死在 MX_TIM3_Init();
因为bootloader程序使用了tim3，并且app中也用到了tim3，在app程序运行至tim3初始化时候，必然卡死，直接下载app无问题，由于无法debug断点调试，调试半天，更改各种配置，都无法解决这个问题。顾选择先搁置，在bootloader中使用了一个不用的定时器tim7，暂时解决。
问题5：IAP升级固件卡死
之前全是通过仿真器下载调试，最后开始尝试使用IAP下载调试，发现：
1. APP程序A，仿真器下载后，能通过bootloader成功跳转。
2. APP程序A，在仿真器下载后，在通过IAP下载，也能成功跳转。
3. 通过IAP，先下载APP程序B，再下载APP程序A，无法成功跳转，通过网上的各种解决办法均无法解决。
4. 在keil环境下生成的bin文件，IAP，先下载B，再下载A，能成功跳转。
5. 把Keil环境下的A工程，移植到cubeIDE，重新生成bin文件，效果同1,2,3
调试过程中有如下发现：
1. cube仿真器下载和IAP下载对比，memory的头部相同，但是IAP下载占用存储大一些。
2. 方法2和方法3对比，memory头部相同，尾部相同一个能跳转，一个不能跳转
3. 同样的led闪烁工程，只改变延时参数后，方法3也不能跳转
4. 同样工程，keil的生成的bin，4kB，cubeIDE生成的bin，30kB
目前现象指向cubeIDE生成的bin有问题，解决办法暂时未知
--------------------------------------------------------------------一条美丽的分割线---------------------------------------------------------------------------------------------------------
中间忙别的，没搞，今天继续调试。
在浮现问题5时候，发现一个现象，通过调试工具，擦除8008000往后程序之后，在下载之前有问题的，cubeIDE生成的bin文件，发现能成功运行，因此，可以将问题再次定位到bootloader程序的擦写功能有问题。
尝试以jlink中断擦除程序后的烧录功能，观察bootloader程序的擦除结果，发现，只擦除了8008000所在的一个FLASH块。
如上，只有Sector 2被擦除，如此问题得到确认。
查看擦除对应代码，有明显的逻辑问题。
更新为如上代码后，随便烧录程序，不在存在问题。
在想办法，把elf转bin时候，发现一些小工具，记录下：
https://www.cnblogs.com/zfyouxi/p/5272672.html
通过上面的步骤，已经可以实现，用xshell通过485给stm32更新固件，接下来需要想办法在unbuntu上实现xhell功能，毕竟xshell没有linux版本。
博主这里选择的是Python脚本方式。
Ymodem的协议详解，参考下文：
Ymodem 协议详解_圆月山庄的博客-CSDN博客
Python源码，参考下文：
Python通过Ymodem协议传输文件_python zmodem_呀儿呦丶的博客-CSDN博客
问题1：下载不成功
表现为使用xshell能下载成功，且正常运行。但是用链接对应的Python代码，无法下载成功。于是乎研究Ymodem的通讯流程，同步调试bootloader代码和Python代码。
标准的Ymodem通讯流程如上图，但是通过观察调试，发现Python代码缺少一次EOT-->NAK流程，于是修改相关代码。
在bootloader代码中，注释掉0x0D和0x0A这两个字符的发送，因为和Python不符合，且协议中也没这两个字符。
void ymodem_ack(void)
{
uint8_t buf[3];
buf[0] = YMODEM_ACK;
// buf[1] = 0x0D;
// buf[2] = 0x0A;
RS485_Send_Data(buf, 1);
}void ymodem_nack(void)
{
uint8_t buf[3];
buf[0] = YMODEM_NAK;
// buf[1] = 0x0D;
// buf[2] = 0x0A;
RS485_Send_Data(buf, 1);
}void ymodem_c(void)
{
uint8_t buf[3];
buf[0] = YMODEM_C;
// buf[1] = 0x0D;
// buf[2] = 0x0A;
RS485_Send_Data(buf, 1);
}
在Python代码中，增加EOT-->NAK流程：
self.ser.write(self.EOT)
print('send EOT1')
is_ack = self.ser.read(1)
if is_ack == self.NAK:
print('rev nak')
# return True
self.ser.write(self.EOT)
print('send EOT2')
is_ack = self.ser.read(1)
if is_ack == self.ACK:
print('rev nak')
# return True
print('send file data end')
通过上面改动，即可实现Python脚本通过RS485给stm32更新固件。
问题2：跳转后，程序不运行
后续，尝试把bootloader触发代码，增加到app程序中。想做到不止上电瞬间才能触发bootloader，任何时候都能触发升级。实现的基本逻辑，就是在app中，485监控串口，侦测到特殊字符串，就跳转到bootloader代码中，实现升级。
实测时候发现，因为bootloader代码和app代码都用到了485，导致跳转后，485不能运行，和之前的TIM情况类似。
经过调试，发现可以用如下方法统一解决这些问题，即在初始化代码前，增加Deinit()代码，重启所有外设。
在cubeIDE中，可以使用如下函数HAL_DeInit()，这个函数内容如下，其功能为将所有外设重启：
HAL_StatusTypeDef HAL_DeInit(void)
{
/* Reset of all peripherals */
__HAL_RCC_APB1_FORCE_RESET();
__HAL_RCC_APB1_RELEASE_RESET();__HAL_RCC_APB2_FORCE_RESET();
__HAL_RCC_APB2_RELEASE_RESET();__HAL_RCC_AHB1_FORCE_RESET();
__HAL_RCC_AHB1_RELEASE_RESET();__HAL_RCC_AHB2_FORCE_RESET();
__HAL_RCC_AHB2_RELEASE_RESET();__HAL_RCC_AHB3_FORCE_RESET();
__HAL_RCC_AHB3_RELEASE_RESET();/* De-Init the low level hardware */
HAL_MspDeInit();
/* Return function status */
return HAL_OK;
}
在bootloader中，其内部为RCC_APB2PeriphResetCmd()函数，通过观察其参数：
#define RCC_APB2Periph_TIM1 ((uint32_t)0x00000001)
#define RCC_APB2Periph_TIM8 ((uint32_t)0x00000002)
#define RCC_APB2Periph_USART1 ((uint32_t)0x00000010)
#define RCC_APB2Periph_USART6 ((uint32_t)0x00000020)
#define RCC_APB2Periph_ADC ((uint32_t)0x00000100)
#define RCC_APB2Periph_ADC1 ((uint32_t)0x00000100)
#define RCC_APB2Periph_ADC2 ((uint32_t)0x00000200)
#define RCC_APB2Periph_ADC3 ((uint32_t)0x00000400)
#define RCC_APB2Periph_SDIO ((uint32_t)0x00000800)
#define RCC_APB2Periph_SPI1 ((uint32_t)0x00001000)
#define RCC_APB2Periph_SPI4 ((uint32_t)0x00002000)
#define RCC_APB2Periph_SYSCFG ((uint32_t)0x00004000)
#define RCC_APB2Periph_TIM9 ((uint32_t)0x00010000)
#define RCC_APB2Periph_TIM10 ((uint32_t)0x00020000)
#define RCC_APB2Periph_TIM11 ((uint32_t)0x00040000)
#define RCC_APB2Periph_SPI5 ((uint32_t)0x00100000)
#define RCC_APB2Periph_SPI6 ((uint32_t)0x00200000)
#define RCC_APB2Periph_SAI1 ((uint32_t)0x00400000)
#define RCC_APB2Periph_LTDC ((uint32_t)0x04000000)
如上，我们可以增加如下参数，来实现将所有外设重启：
#define RCC_Periph_ALL ((uint32_t)0xFFFFFFFF)
添加如下函数实现重启：
void DeInit_All(void)
{
RCC_APB1PeriphResetCmd(RCC_Periph_ALL,ENABLE);
RCC_APB1PeriphResetCmd(RCC_Periph_ALL,DISABLE);
RCC_APB2PeriphResetCmd(RCC_Periph_ALL,ENABLE);
RCC_APB2PeriphResetCmd(RCC_Periph_ALL,DISABLE);RCC_AHB1PeriphResetCmd(RCC_Periph_ALL,ENABLE);
RCC_AHB1PeriphResetCmd(RCC_Periph_ALL,DISABLE);
RCC_AHB2PeriphResetCmd(RCC_Periph_ALL,ENABLE);
RCC_AHB2PeriphResetCmd(RCC_Periph_ALL,DISABLE);
RCC_AHB3PeriphResetCmd(RCC_Periph_ALL,ENABLE);
RCC_AHB3PeriphResetCmd(RCC_Periph_ALL,DISABLE);
}
如上，在bootloader和app的函数初始化前，将所有外设全部重启一次，即可实现因为外设资源冲突导致的错误。
问题3：使用操作系统后，出现跳转到bootloader时钟配置异常
需要在app跳转前，deInit一下时钟配置
uint8_t jump_app(uint32_t app_addr)
{
uint32_t jump_addr;
jump_callback cb;HAL_RCC_DeInit();
// __set_PRIMASK(1);
if (((*(__IO uint32_t*)app_addr) & 0x2FFE0000 ) == 0x20000000) {//app_addr
// __ASM("CPSID I");
jump_addr = *(__IO uint32_t*) (app_addr + 4);
cb = (jump_callback)jump_addr;__set_MSP(*(__IO uint32_t*)app_addr);
cb();
return 1;
}
return 0;
}
问题4：使用操作系统后，跳转后程序卡死，或无响应
前面都是在app通过跳转指令到bootloader升级，因为app使用外设，中断，dma较多，状态总是不确定，跳转后bug角度。
后面意识到，跳转到bootloader还有一个终极解决方案，即重启，重启后一切重来，再去触发烧录固件，看起来是个完美的解决办法。
系统重启的话，可以在需要重启的位置，增加如下代码：文章来源：https://www.toymoban.com/news/detail-501101.html
__set_FAULTMASK(1);
NVIC_SystemReset();文章来源地址https://www.toymoban.com/news/detail-501101.html
到了这里，关于调试笔记-stm32的OTA/IAP 通过485升级固件的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
