摘要：任务名长度刚好卡在 `configMAX_TASK_NAME_LEN` 的边界时，FreeRTOS 会直接触发 `configASSERT`，表现成上电后整机静默。
这篇文章复盘一个很典型、也很容易被误判成硬件故障的问题：系统上电后没有日志、没有闪灯、没有任务运行，最后根因却只是任务名长度和 FreeRTOS 配置值撞在了边界上。文章同时补充了定位路径、修复方式和更稳妥的工程防线。
一个字符就能让 MCU 起不来：FreeRTOS configASSERT 的边界值陷阱
很多嵌入式故障看上去像硬件没启动，最后却死在一个很小的配置细节上。
这次的问题就是这样：系统上电后完全静默，串口没有输出，LED 也不闪，第一感觉像是 MCU 根本没跑起来。真正的根因却只有一个字符的差距。
现场现象
在一个基于 STM32 + FreeRTOS 的控制项目里，固件烧录正常，上电后却出现了非常“硬件化”的症状：
- 没有启动日志
- 周期指示灯不闪
- 任务没有运行迹象
- 重新烧录和复位都不能恢复
如果只看表象，很容易把排查方向放到这些地方：
- Bootloader 是否跳转失败
- 时钟是否没有起来
- 堆栈是否损坏
- 某个外设初始化是否卡死
但断点打进去以后，程序其实已经进入了 FreeRTOS 内部，只是卡在了断言路径里。
真正的根因
问题出在任务名长度和 configMAX_TASK_NAME_LEN 的边界碰撞。
示意代码大概是这样：
#define configMAX_TASK_NAME_LEN 16
/* FreeRTOS 内部存在类似检查 */
if (strlen(name) < configMAX_TASK_NAME_LEN) {
/* 正常处理 */
} else {
configASSERT(0);
}
如果某个任务名的长度刚好也是 16，那么判断条件就是：
16 < 16
结果当然是 false，于是直接触发 configASSERT。
麻烦在于，很多项目里 configASSERT 的默认实现都很“硬核”：
#define configASSERT(x) if ((x) == 0) { taskDISABLE_INTERRUPTS(); for( ;; ); }
这意味着一旦断言失败，系统会：
- 关闭中断
- 停在死循环里
- 不再调度任何任务
从外部看，它就像“根本没启动”一样。
为什么这种问题特别难查
这个坑麻烦，不在于原理复杂，而在于它很会伪装。
1. 编译期完全不会提醒
任务名长度超边界不是语法错误，也不是类型错误。编译器看不出来，链接器也看不出来，只有运行到那一行的时候才会炸。
2. 现象太像硬件故障
没有日志、没有心跳、没有任务，看起来就像系统时钟没起、代码没跑、或者板子没上电。
3. “16 个字符应该刚好够”这件事很容易让人放松警惕
很多人看到 configMAX_TASK_NAME_LEN = 16，会自然理解成“最长可以放 16 个字符”。但具体实现是不是“<= 16”还是“< 16”，如果不去看源码，很容易想当然。
修复不难，关键是别只修一次
这类问题的直接修复方案很简单：
- 把
configMAX_TASK_NAME_LEN调大，至少留出余量 - 把长任务名改短
- 在调试版本里保留断言，但让断言可见
更稳妥的做法是同时补三层防线。
做法一：配置永远别卡边界
如果你估计任务名最长会到 16，那配置就不要写 16，至少往上留几个字符。
#define configMAX_TASK_NAME_LEN 24
这个做法没什么技术含量，但很有效。
做法二：给任务创建加静态检查
如果项目里任务名大多是固定字符串，可以在封装层做长度校验，尽量把问题前移。
#define TASK_NAME_SAFE_LEN 24
或者在创建任务的统一入口里，明确约束命名长度，而不是让各个模块各自命名、各自踩坑。
做法三：别让 configASSERT 默默把系统闷死
调试阶段的断言当然应该保留，但最好让它留下可观察的信息，比如：
- 记录失败文件和行号
- 打印最后一次错误
- 触发软复位前保留错误码
否则一旦断言路径只剩“关中断 + 死循环”，现场就会非常像黑盒。
这个案例暴露的不是字符串问题，而是边界意识问题
从工程角度看，这不只是“任务名太长”。
它反映的是另一件更普遍的事：我们对很多配置项的理解，停留在“看名字猜语义”，而不是“看实现确认语义”。
像下面这些值，都很容易踩同类坑：
- 队列长度
- 栈大小
- DMA 缓冲区长度
- 定时器超时阈值
- 字符串上限
只要系统里有“刚好够”的配置，后面大概率就会遇到“刚好不够”的那个现场。
可以直接带走的检查清单
如果你的项目也用了 FreeRTOS，可以顺手检查这几件事：
configMAX_TASK_NAME_LEN是否给了实际余量- 任务名是否有统一命名约束
configASSERT失败时能否留下可观测信息- 调试版本里是否保留了断言路径
- 是否定期用
uxTaskGetStackHighWaterMark()看任务栈水位
最后一句
很多嵌入式故障不是“大错”，而是边界值和默认实现凑到一起之后，刚好把系统送进了最难观察的状态。
这次只是一个任务名。下次可能就是队列长度、DMA 缓冲区，或者某个你以为“正好够用”的配置项。
Comments NOTHING