STM32F4 iap 跳转后在APP中时钟出错的问题记录

最新推荐文章于 2024-09-19 10:06:11 发布

原创最新推荐文章于 2024-09-19 10:06:11 发布 · 890 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#stm32 #单片机 #嵌入式硬件

学习记录专栏收录该内容

8 篇文章

订阅专栏

本文记录了STM32F4平台下USBHOST功能无法正常工作的问题及解决过程。问题出现在boot阶段未配置USBHOST所需时钟，在app阶段虽已配置但依然存在问题。通过调整时钟配置最终解决问题。

平台是STM32F4

boot中因为不使用usb host功能，所以没有配置对应的时钟；在app中使用了usb host功能，配置了对应的时钟，pllq配置为7,336/7=48Mhz.

之前可以用，今天测试发现不能用了。感到无力解决，查找帖子，有说是boot和app的中断问题，有说是时钟配置的不一致问题。首先个固件中断是一致的，我甚至关掉了boot中的timer中断，无果。

后来尝试修改时钟，改好了，这里要感谢这个文章：(90条消息) 记录gd32f303 IAP代码跳转卡时钟初始化问题_啊？这...的博客-优快云博客_gd32时钟初始化不了

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

yangzichen

关注关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

stm32 bootloader启动正常，APP程序会在时钟配置出错原因分析

ApexYuan

09-24

4326

实验环境 STM32F411芯片 HAL库利用CubeMX生成的Bootloader和APP工程现象描述将Bootloader和APP程序分别下载到板子上，发现程序会死在Error_Handler()的while(1)循环中。具体调试发现程序是在执行HAL_RCC_OscConfig()函数的PLL 配置部分检测到当前PLL已经被配置为了系统时钟而返回了HAL_ERROR的返回值导致进入了Error_Handler()。分析网上搜索了一下，发现了一种说法：PLL在启动之后便不能够重新配置。为

STM32F4 IAP 跳转 APP问题

qinbo1234567890的博客

12-14

4420

IAP 的作用，网上其他资料已经有很多介绍了，这里放一个链接，不进行深入的介绍。本文的关注重点是Bootloader在跳转APP程序中出现的问题。

参与评论您还未登录，请先登录后发表或查看评论

1 条评论

萤火二号 2025.11.22
感谢，问题已解决

【问题】 STM32 从 BOOT 跳转 APP 后运行失败的解决方案贴搜集

嵌入一下?的博客

04-12

2270

主要就是遇到一个BOOT跳转APP后运行失败的问题，网上找的帖子搜罗而来

iap升级后定时器混乱

杨飞的博客

09-11

610

跳转前关闭所有中断，跳转app初始化完后再开启，定时器初始化尽量放在前面，最好设置完中断向量表后就初始化

关于STM32的IAP与APP互相跳转

weixin_30922589的博客

07-24

2799

关于STM32的IAP与APP互相跳转之前做了一个不带系统的IAP与APP互相跳转，在网上找了资料后，很顺畅就完成了，后来在IAR集成开发环境下，IAP无系统，APP用UCOS系统做互相跳转出现了很多问题。现将IAP学习过程和实际遇到问题总结一下。首先说一下什么是IAP。IAP（In Application Programming）即在应用编程，IAP是用户自己的程序在运行过程中对User...

STM32F4XX IAP跳转到app uCOSIII上卡死的问题

02-21

2561

最近在搞一个SD卡的IAP升级，首先弄了个bootloader,再写一个APP，他们必须存储在不同的FLASH地址里，这里我就不讲了，关于IAP升级的方法网上很多，我说下我做这个时遇到的问题单个的Bootloader 和APP在地址0x800000上运行的时候都是OK的，且Bootloader + app(无uCOSIII系统)，运行也是没有问题的；但是但Bootloader + a...

STM32执行IAP升级后不能进中断

baidu_40807171的博客

02-29

2535

的中断是打开的，所以才会进入中断服务函数，从而导致内存非法访问，导致卡死。，现象一样（解释：其实不调用也会卡死，只是测试过程中只留意了。卡死，并且查看内存发现这里的变量的值有些奇怪，并且指针不在。就会出现上述现象，不调用则不会卡死，怀疑是中断没打开，在。所以，综合上述问题，最终有两种方法比较好，我选择的方法二。，理论上应该是没有关系的，但是还是把时基换成一致试试。前的部分代码，并且这段代码很短，执行结束。中，在开启任务调度器的时候，会执行。，在这个函数中会执行一个开中断，将。中断，并未关闭，导致在跳转到。

STM32F4 IAP学习笔记

会飞的鱼的博客

09-05

7310

STM32 IAP学习一、 IAP介绍 IAP（in application programming）即在应用中编程。用于用户在程序运行的过程中对user flash部分的区域进行烧写，主要用于产品发布后，固件程序进行更新升级。因此设计固件程序时需要编写两个项目代码，第一个项目称为BootLoader程序，主要通过外设通信（UART、USB、ETH等）来接收程序或数据，这段程序通...

精选资源

STM32CUBEMX+IAR+IAP应用程序升级(STM32F411VET6)

09-15

在STM32中，IAP通常通过预留一部分Flash空间作为Bootloader区域，用于接收和验证新的应用程序固件。当新固件下载并验证成功后，Bootloader会跳转到新固件的入口地址执行，完成升级。实现IAP的关键步骤包括： 1. ...

STM32 IAP固件升级跳转后卡死可能存在的原因

weixin_39457767的博客

05-26

3766

导致跳转到APP代码时运行到时钟配置就卡死，而时钟没配置成功就无法初始化IO口，也没法发出信号做出提示，看着像app区的代码不运行，但其实还是运行了的。分析：APP代码中需要清除bootload中外设的初始化，否则在APP中的初始化无法成功，而且STM32CubeMX生成的HAL，下层函数大部分都是while形式的，初始化不成功就会卡死，如果这个时候设置了看门狗，就会复位。使用IAP固件升级，本质上就是代码地址的跳转，从bootload代码跳转到APP代码。2、APP区重新清除设置并配置时钟参数。

STM32因为BOOT和时钟造成的异常的调试过程

Ant-Yuan

07-16

2524

前两天朋友寄过来一个stm32f103的板子让我帮他调试下：先检查电源，发现ARM3.3v电源正常，试着连接了jtag，发现可以烧写程序，但debug发现没有跳转到0x8000000地址，而是跳转到了0x1FFF020地址这个应该是ARM内部的厂家专用的地址，看了原理图连接，发现HSE的时钟焊错了，原理图上是8M的晶振，焊接成了16M 另外BOOT0 引脚被置为1了，这样启动时就不会跳转

STM32的IAP跳转到APP后卡死在HAL_Delay()延时函数问题分析与解决

ge2ming的博客

05-30

3143

因为使用了操作系统，所有使用TIM2做为HAL_Delay()延时函数的时基。当程序充IAP跳转到APP之后，程序卡死在MX_SDADC1_Init();中，因为该函数调用了HAL_Delay()延时函数；而uwTick一直没有计数导致。在APP的程序中，调用HAL_Init();之后，开启中断即可解决该问题。

STM32 BOOT成功跳转到APP但APP不运行问题解决

2401_83105703的博客

04-27

2055

百度了一下可能的原因有人说是因为PLL不能二次配置倍频否则会进入void Error_Handler(void)，我就意识到之前的BOOT和APP时钟配置是一致的正常跑，现在的BOOT和APP配置不一致所以跑不了。自己写了个STM32F103RCT6的boot 首先使用boot程序改了下载地址和中断向量表这些代码中的打印作为APP进行验证正常跳转运行。但是将BOOT时钟改为和APP一样或者把APP时钟改为和BOOT一样都不太合适不通用，既然是PLL导致的问题，那我不用PLL不就可以了？

stm32F105RC6 U盘升级实验跳转APP后中断出错问题

Initdev的博客

06-11

2109

最近在做STM32F105的U盘升级功能，其中bootloader中的FLASH写入，APP跳转等均参考了正点原子的F1串口IAP实验。值得注意的是F103的USB是不带HOST功能的，上次做的INIT Kit小板就使用了103的芯片，导致没办法加U盘升级功能。在移植好USB Host 功能后（F1的usb打算后续专门写一篇，这里就不介绍移植的工作了），移植FATFS文件系统，然后测试能够成功识别...

STM32 Bootloader跳转到APP程序中无法启动实时系统

u011790904的博客

03-01

5977

STM32 Bootloader跳转到APP程序中无法启动实时系统一、问题描述： STM32G431 bootloader跳转到APP中执行，能够进入APP的main函数，但main函数里创建实时系统（CMSIS-RTOS2）失败。二、问题解决过程：首先明确：APP程序稍作修改（去掉中断向量偏移，flash起始地址改为0x08000000），不用bootloader，直接烧录到单片机里是肯定可以执行的，实时系统也是可以运行的。以下是bootloader跳转处的程序（bootloader也用的是CMS

stm32 IAP引导两个APP出现的问题及解决方法

xue781565914的专栏

04-29

2948

最近在做bootloader引导app时发现如果APP有操作系统时，会引导不起来，现象如下：平台：stm32H743 采用stm32cubemx配置的HAL库测试方式：上电后运行boot loader，bootloader是裸机运行。由bootloader引导第一段APP，此app由freertos。再通过第一段app运行第二段app，此app也由freertos. 1.由bootloader引导第一段APP ...

stm32 IAP APP 相互跳转实验（keil4 jlink STM32F407ZE）

shengbohu的博客

03-12

7087

1、实验目标： STM32 IAP学习时，希望有一个快捷的方式去实验IAP与APP之间的相互跳转。 1）验证IAP跳转至APP 2）验证APP通过软件reset跳转至IAP （避免再一开始就实验完整的IAP过程，编写BootLoader，编写 APP，再通过PC工具下载APP代码，然后再看是否能...

STM32 实时时钟（RTC）的配置和时钟切换

xingyuanelectric的博客

09-19

2428

目前硬件核心板存在一个问题，外部32.768KHz的晶振经常无法起振，硬件工程师将晶振两端的1MΩ电阻去掉，电容从10pF换成6pF后大部分能起振了，个别的还是不行。目前是外部LSE无法起振的情况下直接死机，为了让上位机知道核心板是否在正常工作，要保证外部晶振无法起振的情况下切换到内部晶振，系统其他功能还能正常工作。仿真的时候可以看到，外部晶振没有起振的情况下死机而无法正常运行，为了解决此问题，要修改超时的库函数，并且切换到LSI。通过以上操作就完成了RTC的配置。4、时钟树配置：选择外部晶振：LSE。

Stm32 bootloader 与APP 跳转的方式和问题点。

最新发布

03-19

<think>好的，用户想知道如何在STM32F4上通过串口实现IAP的Bootloader功能。首先，我需要回顾一下IAP的基本概念和STM32F4的相关知识。IAP允许在应用程序运行时对微控制器的Flash存储器进行重新编程，这在固件更新时非常有用，无需使用专用的编程器。根据用户提供的引用，特别是引用[3]，里面提到Bootloader和APP程序存放在不同的Flash地址区域。因此，首先需要规划Flash的分区。STM32F4的Flash起始地址通常是0x08000000，Bootloader需要放在这个起始地址，后面接着APP程序。需要确定Bootloader的大小，通常根据功能需求，比如是否需要支持多种通信协议、是否需要加密等，来分配足够的空间，比如0x08000000到0x0800FFFF，剩下的给APP。接下来是Bootloader的设计。Bootloader需要通过串口接收新的固件数据，并写入到APP区域。这里需要处理串口通信协议，可能包括数据包的结构、校验机制（如CRC）以及错误处理。同时，Bootloader需要能够跳转到APP程序执行，这涉及到设置堆栈指针和复位向量。引用[3]中提到的代码结构可能有用，需要检查向量表的偏移，确保APP程序的中断能正确响应。然后是APP程序的配置。在编译APP时，需要修改链接脚本，将程序的起始地址设置为Bootloader之后的区域，比如0x08010000。同时，APP的中断向量表也需要相应偏移，以便正确指向新的中断服务程序。此外，APP需要包含跳转回Bootloader的机制，比如通过特定命令或引脚触发，以便再次进行固件更新。通信协议部分，用户提到使用串口，因此需要设计一个可靠的数据传输协议。可能需要将固件分为多个数据包，每个包包含序号、数据和校验码。Bootloader接收到数据后，先进行校验，确认无误后再写入Flash。此外，还需要处理可能的传输错误，如超时重传或请求重发。在实现过程中，需要注意Flash编程的步骤：解锁Flash，擦除目标扇区，写入数据，锁定Flash。STM32F4的HAL库提供了相关的函数，如HAL_FLASH_Unlock(), HAL_FLASH_Program()等，需要正确使用这些函数以避免硬件错误。测试和调试也是关键步骤。可能需要用STM32CubeMX进行硬件配置，比如时钟设置、串口初始化等。引用[2]提到使用USB DFU，但用户的问题是关于串口的，所以需要专注于UART的配置。在调试时，可以通过LED或串口日志来指示Bootloader的状态，方便排查问题。最后，安全性考虑。虽然用户没有明确提到，但固件更新过程中的校验和加密可以增加安全性，防止恶意软件注入。比如使用数字签名或AES加密，但这可能会增加复杂性和资源消耗，需要根据实际需求权衡。总结步骤：Flash分区规划、Bootloader开发、APP配置、通信协议设计、Flash编程、跳转机制、测试调试、安全性增强。需要参考用户提供的引用内容，特别是关于Bootloader和APP的分区设计，以及串口IAP的具体实现方法。</think>### STM32F4通过串口实现IAP Bootloader的步骤 #### 1. **Flash存储规划** - **Bootloader区域**：从Flash起始地址`0x08000000`开始，分配固定大小（例如16KB，地址范围`0x08000000`–`0x08003FFF`）[^3]。 - **APP区域**：紧随Bootloader之后，例如从`0x08004000`开始，剩余空间用于存储主程序。 - **参数存储区**（可选）：用于保存升级状态或校验信息。 #### 2. **Bootloader程序开发** - **初始化配置**： ```c // 配置时钟、串口、Flash接口 HAL_UART_Init(&huart1); // 使用UART1通信 __HAL_RCC_FLASH_CLK_ENABLE(); ``` - **通信协议设计**： - 定义数据帧格式：`[包头][命令字][数据长度][数据][校验和][包尾]`。 - 使用ACK/NACK机制确认数据接收状态。 - **固件写入流程**： 1. 接收擦除指令，擦除APP区域对应的Flash扇区。 ```c FLASH_Erase_Sector(FLASH_SECTOR_1, VOLTAGE_RANGE_3); // 擦除第1扇区 ``` 2. 逐包接收数据并写入Flash： ```c HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, target_address, data); ``` 3. 校验固件完整性（如CRC32）后跳转至APP。 - **跳转到APP的代码**： ```c void JumpToApp(uint32_t app_address) { typedef void (*AppEntry)(void); AppEntry app_entry = (AppEntry)(*(__IO uint32_t*)(app_address + 4)); __set_MSP(*(__IO uint32_t*)app_address); // 设置主堆栈指针 app_entry(); // 执行APP复位中断服务程序 } ``` #### 3. **APP程序配置** - **修改链接脚本**： ```ld MEMORY { FLASH (rx) : ORIGIN = 0x08004000, LENGTH = 256K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K } ``` - **中断向量表偏移**： ```c SCB->VTOR = FLASH_BASE | 0x4000; // 在SystemInit()中设置 ``` - **添加跳回Bootloader的接口**： ```c if (user_button_pressed) { NVIC_SystemReset(); // 复位后进入Bootloader } ``` #### 4. **上位机工具** - 使用Python或QT编写工具，将HEX/BIN文件按协议分包发送。 - 示例Python发送代码： ```python import serial with open("firmware.bin", "rb") as f: data = f.read() ser = serial.Serial("COM3", 115200) for packet in split_into_packets(data): ser.write(packet) while ser.read() != b'ACK': # 等待确认 ser.write(packet) ``` #### 5. **关键问题与优化** - **波特率与超时**：建议使用115200bps及以上，并设置合理超时（如200ms）。 - **断点续传**：在参数区记录已接收的包序号，避免重复传输。 - **加密与签名**：可添加AES加密或RSA签名验证（需Bootloader集成算法库）。 --- ###