stm32待机模式被意外唤醒之原因分析

最新推荐文章于 2024-04-23 16:36:19 发布

冻结的鱼

最新推荐文章于 2024-04-23 16:36:19 发布

阅读量1.6k

点赞数 31

分类专栏： ST相关文章标签： stm32 嵌入式硬件单片机

本文链接：https://blog.csdn.net/u014319604/article/details/137032663

版权

ST相关专栏收录该内容

62 篇文章 4 订阅

订阅专栏

1. 故障现象

客户在项目中使用 STM32G0B1, 由产品内置电池供电. 客户在程序中有使用到 standby 模式, 通过 WKUP2(PC13), WKUP6 引脚唤醒. 除此之外并没有其它唤醒源. 代码中有使用到 RTC,但只是用来记录日期和时间, 并没有参与 standby 的唤醒.

有两种故障现象 :

第一种 : standby 被意外唤醒, 即使两个 WKUP 引脚均无触发信号.
第二种 : PC13 引脚上输出一 1Hz 的方波, 即使代码中并没有配置.

Figure 1 PC13 引脚输出 1Hz 方波, 原因未明
故障是随机, 一般两到三天可能会出现, 暂未发现固定规律. 一旦出现, 按复位键无法恢复, 必须断电后上电才会恢复正常.

2. 故障分析

因为故障表现为断电后才能恢复, 所以判断与 RTC 域相关. 拜访客户后, 查看 RTC 和 TAMP相关寄存器,结果发现寄存器内容均于 0.
查看勘误手册, 在 2.2.6 节中发现 PC13 可能会干扰 LSE

Figure 2
但怎么看都跟此问题应该不相干. 为了缩小问题范围, 现场临时做了一个测试程序. 只用
WKUP2(PC13)引脚唤醒 Standby, WKUP6 则直接不用. 再代码烧进程序, 结果问题依旧, 仍然
是莫名被唤醒. 查看唤醒信号源, 结果发现 PWR_SR1.WUFI=1. 其定义如下 :
在这里插入图片描述
为内部唤醒线来的信号. 但具体是指什么并不清楚.
鉴于客户急于想解决问题, 因此, 首先想到一个 workaround. 即, 先对 RTC 域复位. 在现场测试了下对 RTC 反初始化, 结果一切都恢复正常了. 其实, RTC 域复位还可以用下面几行代码来实现 :

__HAL_RCC_PWR_CLK_ENABLE();
 HAL_PWR_EnableBkUpAccess();
 __HAL_RCC_BACKUPRESET_FORCE();
 __HAL_RCC_BACKUPRESET_RELEASE();
 HAL_PWR_DisableBkUpAccess();

至此, 客户至少有了一个 workaround 措施, 问题变得没那么紧急了. 接下来就需要查找根本原因了.

首先用 PC5 替换 PC13, 由 PC5 来做为 Standby 的唤醒源. 让客户做压力测试, 看看问题跟PC13 引脚到底有没有关系 ? 结果在测试了一周后, 问题重现. 因此得出结论 : 问题与 PC13 引脚无关. 我们不得不转换方向 .

排除了触发信号, 那么剩下的就只可能是与操作 RTC 域相关了. 客户的代码中, 与操作 RTC域相关的操作只有更新 RTC 的日期和时间操作. 客户产品是通过 CAN 总线经转换器连接 PC 的,每次连接 PC 时, PC 会发送消息给到 MCU，要求更新 RTC 日期和时间. 于是要求客户想办法让更新 RTC 的操作变得更加频繁. 很快客户反馈, 如果通过 PC 连续多次发送消息让 MCU 频繁更新RTC 的话, 问题很容易重现 ! 至此, 问题出现重大转机 !

问题变得很容易重现, 也就意味着距离找到原因不远了.

于是接下来, 让客户将更新 RTC 的操作直接由 systick 中断来触发, 每隔一定时间就更新一次RTC. 测试结果为 : 同样容易重现.

于是要客户将更新 RTC 的相关代码发过来看看.与此同时, 客户自已发现 :
在这里插入图片描述
如上所示, 图中蓝色所选的两行代码原本是没有的, 如果加上, 问题消失。客户询问原因.
我立即推断客户可能没有对 rtctime 这个变量做完整地初始化. 于是让客户在定义 rtctime 这个局部变量时, 同时对其进行初始化, 然后做对比测试 :

RTC_TimeTypeDef rtctime = {0};

测试结果为正常!
至此, 我们终于找到问题触发点了. 正是由于这个局部结构体变量未初始化, 导致其值一开始就是个未知的随机值, 在后面 RTC 更新操作前, 其部分成员并未显式赋值, 因此, 其值仍然为一随机值. 在 HAL_RTC_SetTime()函数中, 有这么一行语句:

hrtc->Instance->CR |= (uint32_t)(sTime->DayLightSaving | sTime->StoreOperation);

很明显, DayLinghtSaving, StoreOperation 由于未显式赋值, 其值为随机值, 结果在运行完这一行代码之后, RTC_CR 寄存器会被写入一个随机值! 一个不确定的随机值写入控制寄存器会发生什么就难以预料，这也就不难理解为什么故障会有两种不同的现象了.
修改后的代码在经过半个月的压力测试后, 问题不再重现. 至此, 问题可以判定为解决.