1. NuttX 错误排查概述
做嵌入式开发，说白了就是跟各种错误打交道。我在NuttX社区混了这些年，最深的体会就是：错误不可怕，可怕的是不知道怎么查。这一章，我就把常见的错误类型和排查思路捋一捋，都是实战中摔出来的经验。
核心观点：NuttX的错误排查，本质上是一个「假设-验证」的闭环。你猜原因，然后去验证，对了就修，错了就换一个假设。
1.1 NuttX常见错误类型
我根据项目经验，把NuttX里的错误分成了四大类。你想想看，是不是都遇到过？
| 错误类型 | 典型表现 | 常见根因 |
|---|---|---|
| 断言失败 | 系统挂死，串口打印ASSERT信息 | 指针空、参数越界、状态机异常 |
| 内存溢出 | malloc返回NULL，系统随机崩溃 | 内存泄漏、栈溢出、堆碎片化 |
| 任务挂起 | 某个任务不跑了，其他任务正常 | 死锁、信号量未释放、优先级反转 |
| 驱动错误 | 外设无响应、数据错乱 | 寄存器配置错、中断处理不当、DMA超时 |
1.2 断言失败：最直接的错误
断言失败，是NuttX留给你的最后一张「遗书」。它会在死之前告诉你：我检查到一个不可能的情况。
举个例子，我在调试一个SPI驱动时，遇到过这样的断言：
# 串口输出
up_assert: Assertion failed at file:drivers/spi/spi_transfer.c line:156
up_assert: assert condition: dev != NULL
up_assert: Current task: spi_worker看到没？它直接告诉你：dev是空指针。这时候别慌，顺着调用栈往上查就行。
我的习惯：遇到断言失败，先看三样东西——断言条件、文件名、行号。这三样能帮你定位90%的问题。
1.3 内存溢出：最隐蔽的杀手
内存溢出这玩意儿，我吃过不少亏。它不会立刻死给你看，而是慢慢折磨你。系统跑着跑着就崩了，而且每次崩的位置还不一样。
为什么会这样？说白了，就是内存被写穿了。你申请了100字节，却写了200字节，后面的100字节就把别人的数据覆盖了。
NuttX里排查内存问题，我一般用这几招：
- 开启内存调试：
CONFIG_DEBUG_MM打开，系统会记录每次malloc/free的调用栈 - 检查栈使用量：
CONFIG_STACK_COLORATION打开，看任务栈还剩多少 - 用heap checker：
mallinfo()函数能告诉你堆的使用情况
我曾经踩过的坑：有一次系统跑三天才崩，查了一个星期才发现是某个中断服务程序里用了malloc。中断里别用动态内存分配，这是铁律。
1.4 任务挂起：系统「假死」了
任务挂起，就是某个任务不跑了，但其他任务还在正常工作。你敲命令还能响应，但那个任务就是不动。
我遇到过最典型的情况是死锁。两个任务互相等对方释放资源，结果谁也动不了。嗯，这里要注意：NuttX默认不支持死锁检测，你得自己想办法。
排查思路是这样的：
- 用
ps命令看任务状态，挂起的任务会显示WAIT_SEM - 用
seminfo看信号量状态，哪个信号量被谁持有 - 检查代码里信号量的获取和释放是否成对出现
# 示例：用ps命令排查
NuttShell (NSH) NuttX-12.4.0
nsh> ps
PID PRI POLICY TYPE NPX STATE NAME
0 0 FIFO KTHREAD N READY Idle Task
1 100 RR TASK N WAIT_SEM app_main
2 100 RR TASK N WAIT_SEM uart_rx看到WAIT_SEM了吗？这就是任务在等信号量。如果它一直等不到，那就是死锁了。
1.5 驱动错误：外设不听话
驱动错误，说白了就是硬件和软件没对上话。我调试I2C驱动时，经常遇到设备无响应的情况。
排查驱动问题，我有个「三板斧」：
- 第一板斧：看寄存器。用
i2c dump或者直接读寄存器，确认配置是否正确 - 第二板斧：看中断。中断有没有触发？触发频率对不对？用
irqinfo查看 - 第三板斧：看时序。用逻辑分析仪抓波形，跟数据手册对比
我建议：调试驱动时，先把CONFIG_DEBUG_I2C或CONFIG_DEBUG_SPI打开。这些调试输出能帮你省一半的时间。
1.6 排查思路与基本原则
说了这么多具体错误，咱们聊聊方法论。我总结了一套排查原则，你试试看：
原则一：先看日志，再动代码
很多人一上来就改代码，这是大忌。日志里往往藏着线索。NuttX的调试输出分很多级别：ERROR、WARN、INFO、DEBUG。先把ERROR级别的都看了，再逐级往上。
原则二：复现问题，稳定复现
不能稳定复现的问题，基本没法查。我一般会写一个测试脚本，反复触发那个场景。如果问题10次能复现8次，那就可以开始查了。
原则三：二分法定位
代码量大的时候，别一行一行看。用二分法：注释掉一半代码，看问题还在不在。在就继续二分，不在就说明问题在注释掉的那一半里。
原则四：怀疑一切，验证一切
别相信「这段代码肯定没问题」。我见过太多人信誓旦旦说没问题，结果一查就是他的代码有问题。怀疑一切，然后用证据说话。
我的经验：排查错误时，把每次猜测和验证结果记下来。哪怕猜错了，也能帮你排除一个可能性。我有个笔记本专门记这些，时间长了就成了自己的「错误模式库」。
1.7 知识体系总览
下面这张图，是我对NuttX错误排查的整体理解。你把它记在心里，排查时就知道该往哪个方向走了。
这张图把整个排查流程串起来了。从错误类型出发，到排查方法，再到工具和原则。你排查时，就按这个框架走，不会乱。
最后说一句：排查错误，心态很重要。别急，别慌，一步一步来。我刚开始时也经常抓狂，后来发现，只要方法对，没有查不出来的问题。