记录STM32的一次不明原因的复位

在调试STM32时,程序在接收到特定事件后发生复位,但未触发Hardfault、NVIC_SystemReset或手动复位。通过检查RCC_CSR寄存器发现IWDGRSTF位被置位,提示独立看门狗复位。经过排查,发现原因是使用STLINK Utility烧写程序时,默认设置使能了独立看门狗(WDG_SW),而程序执行时间较长导致看门狗超时复位。

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

         一次调试过程中,将程序烧写进原先的产品中后,使用IAR和STLINK进行调试,程序在接收到一个事件后,莫名其妙的复位。现象如下:

        1、程序中使能看门狗的程序被注释掉--用于仿真程序。

        2、主循环中有喂狗动作,未注释掉。

        3、接收到一个特定事件,一定触发复位。

       4、 复位前,未进Hardfault, 未执行NVIC_SystemReset(),也没有按复位按钮。

       

         仿真后,跟踪到一个函数后复位,但是在哪一句复位,不一定。所以看不出是否是堆栈溢出导致的。

         继续查找原因,STM32有一个复位原因寄存器,再次上电,仿真,产生事件---- 复位。此时查看STM32的RCC_CSR寄存器,发现与复位前,IWDGRSTF位被置位。

    说明肯定是独立看门狗复位。那么是什么导致独立看门狗复位的呢,我并没有使能看门狗啊?

    突然想到 之前使用STLINK Utility 软件进行烧写过程序,一直对option bytes的下面几项不明白是什么原因,也没有深究。 常用的也就是使能读保护功能。


而下面的User configuration option byte里面的几项从来没有关注。查找手册,找到如下内容:

那么问题就很明显了,在之前烧写时,选择了Automatic mode烧写,此模式默认的option bytes如下

而一般我们只是把读保护使能,并将flash写保护去掉。其他不改。这就导致了这个软件会将WDG_SW使能。所以出现了原先的问题。虽然我没有使能看门狗,但是在上电时,已经由硬件(内核?)使能了看门狗。而我那段程序代码的执行时间较长,导致了此次复位事件。


评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值