由返回错误展开的思考

目前我负责一款物联网的设备的开发与维护，在联网层面上有一个错误的弹窗提醒； 当客户把拍摄照片发给我，让我来判断错误原因的时候，我突然意识到一个问题，那就是一位工程师如果面对一个黑盒产品，我曾经自豪于我构建的日志模块，每当问题发生的时候，我总是会快速的定位问题，甚至于依赖这套框架解决了不少棘手的偶发性

驱动层重构导致项目大乱

干憔悴了, 由于硬件改版, 主要也就是添加了 XIP 功能, 增加USB模块, 由于M7的内核, 涉及到eDMA和cache缓存, 光RAM分区都有ITCM,　DTCM , OCRAM, 现在的情况是某个eDMA通道做搬运的时候总是挂掉, 然后再一路踩死其他通道, TCD直接被踩烂了, 写了个eDM

0812 吐槽

配合的硬件工程师不顶用，实在是太tm坑软件了呀，真遭不住了，天天给底层填坑，玛德真痛苦，还不是我专业领域，他娘的，把问题甩出去 2026-8-17更新 问题找到了，模拟电路输入端的一个分支由于线过长，导致引入了额外的寄生电容，进而影响了输出端的电压。改版前没有把问题考虑和排查清楚，打板后对电压也没有

泛谈踩坑之旅

对于等待某个标志判断的情景，必须带超时检验，不要因为这段死等的代码导致CPU指针卡死在这里，从而导致整个系统崩溃 断言！断言！断言！对函数的入参进行校验非常重要，对开发阶段非常具有帮助，尤其是在C语言的环境下，你往往不知道同伴做了哪些令人窒息的操作，当参数传到你负责的模块里的时候，可能内容值根本不是

备忘录：Cortex-M7 OLED eDMA 双缓冲重构踩坑录