目录前言一、排查记录说明前言在使用 RT-Thread 的过程中我一直被一个诡异的问题困扰在控制台执行reboot命令后系统偶尔会直接卡死无法重启。最近终于抽出时间深入排查顺藤摸瓜找到了真凶。在这里先给 RT-Thread 正名这绝对不是 RT-Thread 的坑本文将完整记录整个排查过程从底层源码到硬件电路再到上位机软件希望能帮到遇到类似问题的同学。一、排查记录说明在 RT-Thread 工程路径\drivers\drv_common.c下我们可以找到控制台复位命令的实现static void reboot(uint8_t argc, char **argv) { rt_hw_cpu_reset(); } MSH_CMD_EXPORT(reboot, Reboot System);深入rt_hw_cpu_reset函数核心代码只有一句内容如下可以看出复位命令最终调用的代码只有这一句SCB_AIRCR SCB_RESET_VALUE;void rt_hw_cpu_reset(void) { SCB_AIRCR SCB_RESET_VALUE; }这条语句的作用是触发单片机的系统级软件复位Software System Reset。我们来看看这两个宏定义#define SCB_AIRCR (*(volatile unsigned long *)0xE000ED0C) /* Reset control Address Register */ #define SCB_RESET_VALUE 0x05FA0004 /* Reset value, write to SCB_AIRCR can reset cpu */SCB_AIRCR的全称是 Application Interrupt and Reset Control Register应用中断和复位控制寄存器属于 ARM Cortex-M 内核的系统控制块SCB。要向这个寄存器写入数据并生效必须遵循 ARM 内核的安全机制高 16 位[31:16]0x05FAVECTKEY 写入密钥ARM 内核规定修改 AIRCR 寄存器时必须在高 16 位写入密钥0x05FA。如果不写这个密钥或者写错内核会直接忽略你的写入操作防止程序意外篡改中断和复位配置。低 16 位[15:0]0x0004SYSRESETREQ 系统复位请求0x0004的二进制是...0000 0100即第 2 位SYSRESETREQ被置为1。当内核检测到该位为 1 时会向 STM32 的所有外设和内核发出一个全局复位信号。结论执行该语句的效果等同于用手按下了开发板上的硬件 Reset 按键或者将 NRST 引脚拉低。软件逻辑没有任何问题。软件部分到此为止视线到硬件上目前很多开发板如正点原子探索者V3或自制核心板会利用 USB 转串口芯片如 CH340、CH343的RTS 与 DTR引脚来控制BOOT0 与 Reset信号从而实现“一键串口烧录”。对于 CH340/CH343 芯片RTS 与 DTR 都是低电平有效。当 RTS 输出低电平时会导致三极管导通从而使BOOT0 引脚变为高电平。在正常使用中我们必须保证 BOOT0 始终为低电平确保系统从主 Flash芯片内部 Flash启动因为我们的代码都保存在这里。根据 STM32 官方参考手册描述复位后在 SYSCLK 的第四个上升沿锁存 BOOT 引脚的值。复位后用户可以通过设置 BOOT1 和 BOOT0 引脚来选择需要的自举模式。也就是我们使用reboot命令或者通过按键拉低Reset管脚时起码要保证复位后接下来四个 SYSCLK 时钟周期内BOOT0 引脚为低电平结合上面的软硬件分析问题的终于清晰了。如果上位机终端软件开启了串口的硬件流控模式会发生什么终端软件使能转串口芯片CH340/CH343的 MODEM 联络信号。串口芯片的RTS 引脚被持续拉低。硬件电路导致单片机的BOOT0 引脚被强制拉高。此时触发reboot复位信号。复位后的第四个 SYSCLK 上升沿内核采样到 BOOT0 为高电平。系统错误地从“系统存储器System Memory”启动PC 指针卡死在下列区间程序无法正常运行表现为“系统卡死”。1fff32eb: ldr r1, [pc, #40] ; (0x1fff3314)1fff32ed: str r2, [r1, #0]1fff32ef: ldrh r1, [r0, #0]1fff32f1: lsls r1, r1, #26所以正常开发时必须关闭上位机终端软件的串口硬件流控模式但是我一直使用的终端软件MobaXterm的串口模式具有BUG无法关闭硬件流控从而就一直卡死后面我尝试使用XCOM、Xshell等终端软件皆正常。复位卡死问题解决有时烧录后程序也会卡死终端输出内容如下\ | /- RT - Thread Operating System/ | \ 5.2.2 build Jul 7 2026 22:29:242006 - 2024 Copyright by RT-Thread teampsr: 0x01000000r00: 0x00000000r01: 0x2000200cr02: 0x080103b4r03: 0x080103b4r04: 0xdeadbeefr05: 0xdeadbeefr06: 0xdeadbeefr07: 0x20001d98r08: 0xdeadbeefr09: 0xdeadbeefr10: 0xdeadbeefr11: 0xdeadbeefr12: 0x00000000lr: 0x0800168bpc: 0x0800c998hard fault on thread: mainthread pri status sp stack size max used left tick error tcb addr usage-------- --- ------- ---------- ---------- ------ ---------- ------- ---------- -----tshell 20 ready 0x00000048 0x00001000 01% 0x0000000a OK 0x20001fe0 N/Atidle0 31 ready 0x00000044 0x00000100 26% 0x00000020 OK 0x200008a0 N/Atimer 4 suspend 0x000000ac 0x00000200 33% 0x00000009 EINTRPT 0x20000cf8 N/Amain 10 running 0x00000044 0x00000800 15% 0x00000014 OK 0x2000150c N/Adebug event崩溃发生在main()函数刚刚被 RT-Thread 内核调用的那一刻甚至还没来得及执行任何代码。其中复位失败也会引发这个问题所以严重怀疑也是MobaXterm的串口BUG换了终端软件目前没有再发生过不过目前使用次数较少等到后续验证。
