解决STM32程序一烧录进去断电或复位即丢失问题

已于 2023-01-20 21:04:56 修改
阅读量1.2w 收藏 40
点赞数 9
分类专栏： 嵌入式 文章标签： stm32 单片机 arm keil mdk 经验分享
于 2022-01-28 14:55:48 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/OMGMac/article/details/122730833
版权
本文分享了一次STM32F103RCT6芯片ISP下载失败的故障排查经历，作者通过检查BOOT配置和测量BOOT0及BOOT1引脚电压，最终定位问题在于三极管接错导致的BOOT配置错误。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

分享一下个人错误经验，之前焊接了一块STM32F103RCT6芯片，配了ISP自动下载电路，焊接好后上电烧写发现可以烧录进去，但是怎么一断电或者一复位怎么程序就没了，连一个简单的LED程序都会没了。一想不对劲，BOOT配置也正常啊，难道我的ISP不行，于是就手动下载，我去结果也不可以。

于是怀疑难道是没有下载到ROM里面，只存在RAM里面，掉电就给我丢失了？
查了一下网上，有人说是可能是没有下载到ROM里面，有人说BOOT配置不对，有人说硬件电路有问题，于是我就查啊查，果然被我发现了，用万用表一查发现我的BOOT0的电压不接VCC怎么都有4.5V左右，而BOOT1的电压则只有0.4V左右，一想不对劲，于是一看我去是三极管接错了，造成我的BOOT配置也错了。难怪程序一下载断电就没了。查了一下技术手册，发现boot的配置如图
在这里插入图片描述
按理说应该是可以烧录进FLASH里面,但是板子重启后程序跑不起来，因此可能是三极管出错BOOT配置混乱，造成没有选择主闪存存储器被选为启动区域。

所以经验分享，如果发现自己做的板子如果配了ISP下载电路或者手动下载发现程序烧录完一断电或者复位程序就没了，一定要检查一下自己的BOOT配置是否正确以及BOOT0和BOOT1这两个引脚的电压是否正常！！！

另外在烧录时候发现虽然我的boot配置不对，但是修改烧写器的配置竟然可以成功下载一次，也不知道什么原因，也拿出来分享一下。烧写器配置如图所示：
在这里插入图片描述

本人水平有限，上述信息仅供学习参考，如有错误和不妥之处，请多多指教。
另外创作不易，请勿抄袭，如果有帮助到大家的话希望大家可以点个赞，谢谢~

【IoT】STM32 FLASH 掉电数据丢失处理策略以及备份机制
产品线负责人
03-23 1万+
1、原因 由于FLASH的擦除和写入的特性，如果在擦除中掉电或者写入时掉电，有可能会出现失败的情况，下次再上电读取就会出错。 擦除的时候掉电，不能保证擦除完全，但是已经擦除的部分，肯定是0xff了。 写的时候掉电，已经写入的就是正确的，电平掉到最低极限工作电压附近时，写入的就无法保证了，地址无法保证，写入的值也无法保证。没有写到的，肯定还是 0xFF。   2、解决方式 2.1、硬件方式...
stm32 Keil V5 开发pack突然丢失
10-27 960
ST与其他ARM开发包下载链接安装包下载链接开发包下载
STM32 烧录程序后上电不工作，但调试模式下可正常工作的解决办法
路过的熊的博客
08-24 6752
STM32 烧录程序后上电不工作，但调试模式下可正常工作的解决办法
解决STM32每次下载程序都需要断电
07-14
在给一些STM32开发板下载程序时，都需要断电才能重新下载程序，本文给出一个不需要断电直接按复位键就可以下载程序的方法。
stm32f103 boot引脚
qq_40170041的博客
03-20 883
在STM32F103微控制器中，配置BOOT引脚通常是为了进入系统的引导模式（Bootloader模式）或用于特定的调试和固件更新操作。STM32F103系列微控制器通常有两个BOOT引脚：BOOT0和BOOT1。它们的默认配置决定了设备在启动时如何寻找和执行代码。BOOT0：这是一个关键的引脚，用于决定设备启动时从哪种存储介质加载代码。 当BOOT0引脚连接到VDD（高电平）时，设备从系统存储器（通常是内部Flash）启动。 当BOOT0引脚连接到VSS（低电平）时，设备尝试从Bootloader区域启动
STM32最小系统板下载后断电程序丢失问题
qq_49268822的博客
04-06 623
前者为运行代码时跳线帽接口，后者是下载代码时的跳线帽接口。
stm32f103烧录程序后，断电和重启程序不自启动
jack_pipi的博客
05-17 6686
但传感器采集不到数据，分析可能是reset只给单片机及外围电路重启了，传感器供电还在没有重启，所以传感器没有初始化成功，无法收到采集的数据。最近使用单片机接传感器采集数据，把程序烧录进去后只能运行一次，断电或者reset后程序都不再运行，一直以为是硬件问题，烧录程序到RAM中了，但感觉又不太对劲，印象中程序只需烧录一次就可以了。查阅资料大概意思是，再次上电后外围电路可能供电不及时，系统就已经完成初试化了，所以修改程序，在main()中，在各种初始化之前加入一个一秒的延迟函数，再次断电后程序可以自启动了。
STM32 Flash操作（擦写）过程中器件复位导致数据丢失问题
热门推荐
暖暖_的_纠结的博客
06-12 1万+
1.问题描述 产品在运行过程中需要保存一些断电不丢失的数据，为此将数据保存在STM32内部的flash中。但是测试人员在测试的过程中，修改了数据参数，直接断电重启机器，并没有等待flash的操作时间，导致原有的数据丢失。 2. 原理分析 本产品硬件平台是基于STM32F429，采用HAL库开发。在操作内部flash这部分中，查看数据手册得知： 对于操作128KB的扇区擦写32位数据...
STM32调试正常断电重启后，程序跑飞
黑猫警长的博客
07-03 4031
问题描述： 　　这几天做了个新项目，程序是从旧项目一直过来的，程序调试中都没有问题。烧录后面跑的也是正常。甚至用串口工具ｒｔｓ重启都是好的，就是断电重启后，或者软件重启后，程序跑飞了（几个全局变量数据异常）。 解决方式： １、检测是否内存溢出，导致程序跑飞； ２、检测EPRom，是否存储是否正确，比如ｃｈａｒ存入一位即可（之前的项目是应为这个导致几个参数一直错误）； ３、查看堆栈是否溢出或者分配错误 ４、（这个项目的解决方式）重新建立ｋｅｉｌ工程（eclipse工程），由于项目更换了芯片，导致内
STM32单片机常见的工作异常现象分析及解决方案
01-19
说明程序运行一段时间后，不工作了。由于在线调试模式，板子工作正常，无法通过在线调试的方式判断程序运行的异常状态。分析可能的原因：1、初始化过程中，程序陷入死循环。但程序初始化过程中，没有while（1）死...
stm32G030开发板原理图+PCB（可直接打样生产）+程序例子
03-02
在STM32G030中，开发者可以利用FLASH编写和烧录应用程序，且数据在断电后仍能保留。 9. EEPROM（Electrically Erasable Programmable Read-Only Memory）：EEPROM是一种可以电擦除和编程的只读存储器，常用于存储...
STM32程序ＩＳＰ下载方法.pdf
11-05
5. 下载完成后，可以通过复位开发板或重新上电的方式，让STM32从新烧录的程序中启动。 五、注意事项 1. 在进行ISP下载前，确保所有连接都正确无误，以避免可能的硬件损坏。 2. 不同型号的STM32单片机，其ISP启动...
STM32 程序下载神器
09-04
总之，“STM32程序下载神器”是一个实用的工具，它为STM32开发人员提供了一种简单而有效的程序烧录解决方案，使得开发过程更加顺畅。通过深入理解串口通信、STM32的内部结构以及固件烧录原理，开发者可以更好地利用...
STM32的掉电检测程序
11-24
STM32的掉电检测程序，亲测能用。内有详细的讲解文档，很好的学习资料。
STM32对Flash操作导致USART接收丢数据的解决方法
03-16
在产品设计中，使用了STM32片上Flash 模拟了一个EEPROM 的功能，用于存贮数据。在软件调试时，发现开启此功能，会影响到USART 通信，导致偶尔发生个别数据接收不到的现象。该文档说明解决方法！
STM32F103掉电无法保存数据
weixin_43771930的博客
02-09 983
在一个项目中，需要用到掉电保存，按照STM32的数据手册和参考手册，将相关配置写到了程序中，但发现无法将数据写入到FLASH中，数据一直为0，并且当将写入数据在写入的中断中，直接赋值为一个常数时，写入是成功的。之后在掉电中断中，加入了5s的延迟（延迟过程中,LED灯不会闪烁，其他情况下都会按照1s的周期进行闪烁），发现无论PVD中断的配置是上升沿触发、下降沿触发，还是电平触发都是在上电的时候，才会出现LED的5s不闪烁。不过这个很让人不急，应该是和硬件有关系吧，以后在研究了。先完成手上的活再说了。
stm32f103的IAP升级时，部分APP程序功能丢失，串口中断不起作用，怎么办？
乐于分享
10-12 4909
昨天我用stm32f103做IAP升级，APP程序是一个LED闪烁和一个串口1收发数据。结果IAP升级后，发现APP程序只有LED闪烁但是串口1不行甚至引起死机.这种半死不活的现象是最莫名其妙的，它一半在暗示你APP好像移植成功了一半失败了一半。这种现象是最不好找原因的。后来，发现，是有三个窍门的，我决定把这三个窍门分享给大家。 第一个：在从boot程序跳转到app程序之前，必须先单独关闭外设的串...
移植新mcu时，jlink下载调试时运行正常，断电重新上电后程序丢失
qq_53090814的博客
07-29 483
但是这就导致我在新的mcu下，程序在jlink仿真中能正常执行，断点后，程序就“消失“一般。（暂时未检查陈旭是死掉了还是未能正常加载，大概率是未能正常从flash加载吧）2、时钟初始化函数执行后，但是时钟还没有配置完成，就进行外设的初始化，故导致上电后不运行程序。原本的项目，貌似保留了IAP升级功能，给bootloader留了空间，使用。）的时候，在新的链接文件中也对region_ROM_start__添加了偏移量。解决：在时钟初始化函数后添加延时函数。由于目前项目不需要IAP功能，删除也就没什么问题了。
关于STM32重新上电后，程序不能正常运行
qq_49415703的博客
09-23 2982
最近做一个项目，我是通过串口下发数据控制电机转动的角度，在刚下载程序以后，单片机可以正常运行，通过串口下发数据电机也可以正常运转，但是在重新上电以后，串口可以正常发送和接收数据，但是电机就是不能运行，debug调试也是可以，这个时候我就纳闷了，调试可以，数据也正常，为什么重新上电以后就是不能跑能呢？后面想了一下，既然串口可以跑，系统灯也在闪，说明程序并不存在卡死现象，后面经过思索，把定时器初始化放在最前面就完美解决了，主要还是初始化顺序问题，可能是时钟树没开，导致前面初始化没起作用。
立创3507核心板断电后程序丢失
最新发布
04-03
<think>嗯，用户问的是立创3507核心板断电后程序丢失的问题。首先，我需要确定这个核心板的具体型号和使用的微控制器类型。因为立创可能有不同的核心板，但3507可能指的是某个特定型号，比如STM32F103C8T6，这类芯片通常属于ARM Cortex-M系列。不过，也有可能用户指的是其他类型的MCU，比如51单片机或者AVR，但STM32的可能性较大，因为比较常见。 接下来，用户提到断电后程序丢失。这通常涉及到程序存储介质的问题。微控制器的程序通常存储在Flash存储器中，而Flash是掉电非易失的，也就是说断电后程序应该保留。如果程序丢失，可能的原因有几个： 1. **程序没有正确烧录到Flash**：可能在下载程序时，选择了错误的存储器类型，比如误烧到RAM中，但这种情况比较少见，因为大多数开发环境默认烧录到Flash。 2. **Flash寿命问题**：Flash有写入次数限制，通常约10万次左右。如果用户频繁烧写程序，可能导致Flash损坏，但这种情况需要多次擦写才会出现。 3. **电源问题**：在断电瞬间，电压不稳定可能导致MCU异常操作，误触发Flash擦除操作。不过这种情况需要特定的条件，比如电源设计有缺陷，或者在断电时有电压尖峰。 4. **Bootloader设置问题**：如果核心板使用了自定义的Bootloader，可能存在配置错误，导致程序在启动时被清除或跳转失败，但用户可能不会接触到这部分。 5. **芯片损坏**：MCU本身的Flash存储单元损坏，导致无法保存程序，但这种情况通常伴随其他故障现象。 接下来，我需要考虑用户可能的操作错误。比如，是否在下载程序后没有正确验证，或者使用的下载方式有问题。例如，使用串口下载时，如果未正确选择擦除选项，或者下载过程中断电，可能导致程序未完整写入。 另外，可能需要检查硬件电路。例如，核心板的供电是否稳定，是否有足够的去耦电容，确保在断电时不会出现电压骤降或浪涌，影响Flash的保存。此外，检查复位电路是否正常，复位信号不稳定可能导致MCU在启动时无法正确读取Flash。 还有可能是软件问题，比如程序中意外包含了自擦除的代码，比如IAP（在应用编程）功能，可能在某种条件下触发了Flash的擦除操作。需要检查用户程序是否有这样的代码段。 最后，可能需要建议用户尝试重新烧录程序，检查是否每次断电后都丢失，还是偶尔发生。如果是每次都丢失，那问题比较明显，可能是烧录方式或存储器选择错误。如果是偶发，可能与硬件电源或干扰有关。 总结下来，可能的原因包括烧录配置错误、Flash损坏、电源问题、软件自擦除等。需要逐步排查这些可能性，建议用户检查下载设置、电源稳定性，并查看程序代码是否有异常操作Flash的部分。</think>关于立创3507核心板断电后程序丢失的问题，以下是逐步分析及解决方案： --- ### **1. 核心板存储介质分析** 立创3507核心板通常搭载**STM32系列微控制器**（如STM32F103C8T6），其程序存储介质为**内部Flash存储器**。 **Flash特性**： - 掉电非易失性（正常情况程序不会丢失） - 擦写寿命约 $10^4 \sim 10^5$ 次 - **异常丢失程序的常见原因**： --- ### **2. 程序丢失的可能原因** #### **(1) 程序未正确烧录到Flash** - **错误现象**：程序仅在调试时运行，断电后消失。 - **排查方法**： - 检查烧录工具（如ST-Link、J-Link）的配置，确认烧录目标为**内部Flash**而非RAM。 - 在Keil或CubeIDE中，验证`Target Options > Debug > Flash Download`是否勾选**Reset and Run**。 #### **(2) 电源异常导致Flash损坏** - **错误现象**：频繁烧录后程序稳定性下降。 - **关键点**： - 断电瞬间电压跌落可能触发MCU异常操作（如意外擦写Flash）。 - 核心板电源滤波电容不足时，电压波动会干扰Flash存储单元。 - **解决方案**： - 增加电源滤波电容（如并联 $10\mu\text{F} + 0.1\mu\text{F}$ 电容）。 - 避免频繁烧录程序。 #### **(3) 程序代码误擦除Flash** - **错误现象**：程序运行后自动清除自身。 - **排查方法**： - 检查代码中是否包含**IAP（在应用编程）**功能或Flash操作函数（如`HAL_FLASH_Program()`）。 - 避免在未隔离的代码段中执行Flash擦除操作。 --- ### **3. 硬件排查步骤** #### **(1) 检查供电电路** - 使用示波器测量断电瞬间的电压波形，确认无尖峰或震荡。 - 确保VDD电压在 $3.0\text{V} \sim 3.6\text{V}$ 范围内（STM32F1系列要求）。 #### **(2) 验证复位电路** - 复位引脚（NRST）需通过 $10\text{k}\Omega$ 上拉电阻和 $0.1\mu\text{F}$ 电容稳定信号。 - 复位信号异常可能导致MCU无法正确读取Flash。 --- ### **4. 软件配置建议** #### **(1) 烧录配置验证** - 在STM32CubeProgrammer中，勾选以下选项： ```plaintext [Options] > Verify after programming [Options] > Reset after programming ``` #### **(2) 禁用未使用的功能** - 关闭调试接口（如SWD/JTAG）的写权限，防止意外擦除： ```c HAL_DBGMCU_DisableDBGStandbyMode(); // 禁止调试模式下Flash访问 ``` --- ### **5. 极端情况处理** 若上述方法无效，可能是芯片Flash物理损坏： - 尝试更换新MCU芯片。 - 联系立创客服确认核心板设计是否存在缺陷（如缺少写保护电路）。 --- ### **总结** 程序丢失的优先级排查顺序： 1. 检查烧录工具配置 2. 测量电源稳定性 3. 审查代码中的Flash操作 4. 硬件电路验证 通过逐步排查，可定位问题根源并针对性解决。
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

OMGMac

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值