关于RTC的玄学bug分析与解决
发表于|更新于|MCU
关于RTC的玄学bug分析与解决
现象:按键长按或者连续按压导致RTC起振异常;
RTC经过的时间读取出来没有变化,或者变化异常
发现:经过一下午复现排查后,按键背面为晶振区域;我摁下按键的手法会按压到晶振区域导致晶振异常;人按下按键时未按压到晶振区域.无法复现;如图
另外该现象体现在如下方面:
使用LSE为时钟源,可能导致初始化失败;看图,BootLoader成功跳转,app初始化错误;
这是错误发生位置,APP的时钟初始化;
对比APP和BL的时钟初始化以及RTC导致失败的原因分析发现.
bl中仅初始化了HSE,app中还初始化了LSE,使用了RTC硬件资源导致初始化失败
检测使用RTC的时间去处理的函数,例如延时等操作,会一并异常.现象为无法继续运行下去
不在按压RTC器件后,可能现象还会出现,形变还没消失;还会出现上述情况.
得等待结束
总结:
不要接触挤压精密器件部分
硬件布线应考虑布局,按键背面不应该放精密器件
文章作者: Liya Huang
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 wdfk-prog的个人博客!
相关推荐

2025-10-03
HAL_DMA_ERROR_FE错误代码解决方法
[toc] 错误场景: 使用STM32F7芯片 使用CUBE生成配置 使用如下链接代码 https://download.csdn.net/download/qq_39665253/77125064 具体为DMA+USART+FIFO(软件编写)+双串口。将接受到的数据发送回串口助手中。 表面上看收发正常。实际应用时(MODBUS多从机应用),总会丢失数据。debug看串口错误中断,发现EeeoreCode错误代码为10如何定位进入错误中断前的代码,看下面链接 https://blog.csdn.net/u013181595/article/details/69523331 定位进入错误中断代码,可找到这段代码。即进入了FIFO错误中断了观察CUEB串口设置,并没有使用FIFO。 CUBE生成代...

2026-04-01
MCU内核电压不稳导致程序跑飞的现象、原因与影响
@[toc] MCU内核电压不稳导致程序跑飞的现象、原因与影响 一、问题概述本次异常的本质不是单纯的软件逻辑错误,而是内核供电不稳定引发的系统级异常。当芯片内部核心电压不能被稳定维持时,CPU、总线、外设控制逻辑都会受到影响,最终表现为程序执行异常,也就是现场常说的“跑飞”。 这类问题通常具有较强的迷惑性:表面看像是线程异常、定时器异常、偶发 HardFault,甚至像软件定时或中断处理有问题;但实际根因在于供电相关电路未按规格书要求正确连接,导致内核工作电压不稳定。 二、典型现象内核电压不稳时,系统通常不会一上电立即完全失效,而是表现出一定的随机性和偶发性,常见现象包括: 1. 运行一段时间后随机异常系统上电后可以启动,基本功能初期也可能正常,但运行一段时间后会突然出现异常,表现为: 程序卡死 线程调度异常 某些任务不再按预期运行 定时行为紊乱 2. 异常位置不固定问题出现时,表面上的故障点往往并不一致,例如: 有时记录在线程上下文 有时表现为中断处理异常 有时进入 HardFault 有时停在某个看似无关的函数或流程中 这类“落点不固定”的问题,正是供电不稳的典型特...

2026-03-30
FNV-1a 64-bit 在 MCU-32bit 上的实现与取舍:从原理、代码到适用边界
FNV-1a 64-bit 在 MCU-32bit 上的实现与取舍:从原理、代码到适用边界先看核心结论FNV-1a 64-bit 的重点,不是“32 位 MCU 能不能跑 64 位整数”,而是下面三件事: 这个散列为什么能工作。 代码实现里每一步到底在做什么。 哪些场景适合用,哪些场景不适合用。 把这三件事讲清楚后,再讨论 32-bit 和 64-bit 的工程取舍,结构会更稳,也更接近实际选型过程。 FNV-1a 的标准更新过程可以概括成一条固定循环: 状态从 offset_basis 开始 每读取一个字节,先异或进状态 再乘上固定的 FNV_Prime 运算结果保留在固定比特宽度内 对 64-bit 版本,标准常量是: 12#define FNV1A64_OFFSET_BASIS 0xCBF29CE484222325ULL#define FNV1A64_PRIME 0x00000100000001B3ULL 这两个常量不是任意挑选出来的。offset_basis 决定初始状态,FNV_Prime 决定每次吸收新字节后如何扩散已有状态。 先把原...

2026-03-21
一次由 C 位域非原子写入引发的状态上报异常
@[toc] 一次由 C 位域非原子写入引发的状态上报异常在一套嵌入式控制固件中,出现过一类很典型、但又很容易被忽略的异常:传感器物理状态已经持续触发,心跳报文却长时间仍然上报为 0;重新手动触发一次后,状态又恢复正常。 表面上看,这类问题很像采样抖动、消息队列满、或者 CAN 发送延迟。但沿着发送链路继续深挖后,真正的问题并不在总线,也不在消息队列,而是在 C 语言位域写入不是原子操作 这一点上。 先看现象,不要先怪 CAN异常表现有几个很强的特征: 传感器已经进入触发状态,并且维持了很长时间。 心跳报文仍然持续发送,但目标状态位始终是 0。 再次手动触发一次传感器后,状态恢复正常。 不是“完全没报文”,而是“报文一直有,但某一位一直不对”。 这类现象说明一件事:发送通道本身大概率是通的。如果 CAN 队列、发送线程、或总线仲裁是主因,更常见的表现会是丢帧、延迟、或整帧不发,而不是“整帧一直发,但某一位长期错误”。 因此,排查重点不该先放在“是否发出去”,而应该放在“发出去的那 8 个字节是谁构造的,以及构造时有没有被并发写坏”。 位域写入通常是读改写,不是原子更...

2026-03-19
MAX14830 可移植 C 驱动实现分析:一个适合多串口扩展场景的开源基础版本
@[toc] MAX14830 可移植 C 驱动实现分析:一个适合多串口扩展场景的开源基础版本在嵌入式系统中,串口资源不足是一个非常常见的问题。当主控需要同时连接调试接口、通信模组、下位机设备或多路传感器时,片上 UART 数量往往很快成为限制条件。此类场景下,外扩串口芯片通常是更现实的方案,而 MAX14830 就是其中较典型的一种:通过 SPI 或 I2C 总线,可以扩展出 4 路独立 UART,同时提供 FIFO 和 GPIO 能力,适合承担多串口桥接角色。 GitHub 上的 wdfk-prog/max14830,就是一个面向这颗芯片的开源 C 驱动实现。这个项目的重点不在“做了多少高级功能”,而在于它明确采用了 可移植、平台无关、基于 HAL 抽象 的实现思路。对于正在做 MAX14830 接入、板级驱动开发,或者准备搭建多串口扩展方案的人来说,这类代码通常比单平台 Demo 更有参考价值。 仓库地址: https://github.com/wdfk-prog/max14830 项目定位很明确:不是平台示例,而是通用驱动骨架从仓库主页给出的描述来看,...

2026-03-19
M104BPCSX-5024 RFID 驱动与应用层开源实现分析
@[toc] M104BPCSX-5024 RFID 驱动与应用层开源实现分析wdfk-prog/m104bpcsx_5024 是一个面向 M104BPCSX-5024 RFID 模块的开源实现,项目以 C 语言编写,围绕 RFID 模块接入的典型嵌入式应用场景,构建了较完整的驱动层与应用层一体化方案。从仓库公开信息来看,该项目不仅提供了底层协议封装与通信接口实现,还进一步覆盖了多通道轮询、RTOS 线程调度、CAN 总线结果上报以及功耗控制等业务逻辑,具备较强的工程参考意义。 与常见仅停留在寄存器读写或单一通信接口封装的示例工程不同,该项目更接近真实产品环境中的 RFID 子系统实现方式,尤其适合作为以下方向的参考样例: 嵌入式驱动分层设计 SPI / UART 双通信路径抽象 基于 RTOS 的设备轮询任务组织 多通道 RFID 读卡器管理 CAN 总线状态上报集成 一、项目定位与功能概述该项目面向 M104BPCSX-5024 RFID 模块,目标是构建一套可移植、可扩展、适用于多硬件接入方案的驱动与应用实现框架。项目核心功能包括: 对多个 RFID...
评论








