本章是工程能力章①固件体积怎么优化含本书真实账单②崩溃Guru Meditation到底是什么机制③用 addr2line 把崩溃地址翻译成代码行的完整方法含本书真实案例fade 安装顺序错误的崩溃排查全过程。11.1 体积账单先看我们项目的真实数字idf.py size当前发布版text data bss dec hex 118639 53598 362939 535176 82a88段大小存放含义text118639 BFlash代码指令data53598 BFlash 初值 SRAM 运行有初值数据bss362939 BSRAM大头是 IDF 预建的内存池/缓冲区不是我们的变量无初值数据最后两列dec/hex把 textdatabss 加在一起的总大小dec 是十进制、hex 是同一个数的十六进制写法——535176 0x82a88两种记数是同一个数第 0/1 章讲过互转。bin 大小烧录报告l298n.bin binary size 0x2a150 bytes 172368 B 0xd5eb0 bytes (84%) free 分区剩 876208 B体积变化记录我们的真实验证版本bin 大小原因初始 -Og176336 B基线不优化改 -Os162288 B优化等级省 14KBPSRAM 配置170768 B启动代码增加当前含 fade 修复172368 B最终相对 170768 增加约 1.6KB11.2 优化等级到底在改什么优化器是只改代码、不改语义的转换器。常见招式常量折叠x 100 * 2→x 200死代码删除if (0) {...}整段删内联小函数展开到调用处省压栈/跳转强度削减x * 2→x 1删除未用变量/函数没被引用的直接不进固件。选项目标体积速度调试-O0无大慢最好-Og调试友好中中好-Os体积小中一般-O2速度大快差⚠️ 优化会影响崩溃回溯代码被重排/内联后PC 地址和源码行对不齐。先 -Og 查 bug发布再 -Os。11.3 减体积五招-OsCONFIG_COMPILER_OPTIMIZATION_SIZEy省得最多关不需要的组件menuconfig 里蓝牙/WiFi/调试组件按需关别用 double浮点库整体很大printf(%f)等日志等级 INFODEBUG 字符串不进固件定位大头idf.py size-components、size-files找出最占地方的。11.4 崩溃机制Guru Meditation 是什么芯片检测到非法操作 → 进入panic恐慌状态Guru Meditation Error: Core 0 paniced (LoadProhibited)恐慌来源底层CPU 执行了禁止的访存读/写地址越界、访问保护区域内核级异常栈溢出、非法指令软件主动 abort如 ESP_ERROR_CHECK第 6 章。LoadProhibited的机制地址空间被分成很多区各自有访问权限。CPU 去读一个不允许读的地址如 0x00000000或未映射区→ MMU内存管理单元芯片里查这个地址准不准访问的门卫/总线保护→ 异常 → panic。LoadProhibited EXCVADDR: 0x00000000 访问了地址 0 大概率空指针指针的值是 0解引用它Backtrace回溯怎么读Backtrace: 0x4200942f:0x3fca0000 0x4037c123:0x3fca0010 0x42000056:0x3fca0030格式地址:栈指针依次排列第一个是当前卡住的位置后面是“谁调用了它”调用链。栈指针帮我们确认每一层的栈帧栈帧每次函数调用在栈上占用的那一格装着返回地址和局部变量。11.5 addr2line把地址翻译成代码行原理.elf 里带调试信息DWARF记录每条指令对应源码哪一行。addr2line 用地址查这张表。xtensa-esp32s3-elf-addr2line.exe-ebuild\l298n.elf-f-C0x4200942f-e指定 .elf必须有调试信息别删 build-f显示函数名-CC 名字还原成可读形式。在哪跑IDF 终端跑过 export 的窗口2.3提示找不到命令就是工具链没进 PATH先执行 export 再试。习惯每次发布前备份 .elf——把build\l298n.elf复制一份、按固件版本改名存档。旧崩溃日志只有配对的那份 .elf 才翻得动build 一删就永远翻不出来了11.9 有对应的坑。更省事的路idf.py monitor会在崩溃发生时自动把 Backtrace 里的地址翻译成函数名和源码行打印出来日常排查直接看 monitor 输出就行addr2line 是用来理解原理和处理离线日志的。11.6 真实案例fade 顺序崩溃的全排查过程症状第 7 章坑 2Guru Meditation Error: Core 0 paniced (LoadProhibited) EXCVADDR: 0x00000000 Backtrace: 0x4200942f:0x3fca0000 0x4037c123:0x3fca0010 0x42000056:0x3fca0030排查步骤完整方法演示读类型LoadProhibited 非法读EXCVADDR0 空指针翻译 3 个地址addr2line0x4200942f → ledc_ll_get_fade_end_intr_addr ledc 驱动内部 0x4037c123 → ledc_fade_func_install 我们调用的安装函数 0x42000056 → DCMotor::init 我们的代码注意这些地址来自修复前那次崩溃时的固件代码改过之后重新编译当前 build 里同样的行号/地址已经对不上了——翻译历史崩溃日志时必须用产生该日志的那一份 .elf别拿最新 build 去翻旧地址。看调用链DCMotor::init → 调用 ledc_fade_func_install →内部访问通道对象表——表还是空的 → 空指针原因install 放在 timer/channel 配置之前修复把ledc_fade_func_install(0)移到配置之后验证重编译 → 烧录 → 日志正常。方法论翻译地址 → 看调用链 → 想为什么访问空/非法地址 → 修 → 验证。不要瞎试。11.6b 动手实验亲手复现一次崩溃再亲手翻译它光读一百遍不如亲手崩一次。这个实验把 11.6 的案例故意重演一遍前提是你手上已有完整工程8.6 全文复现的motor_control.*两个文件 12.2 的main.cpp也可用随书源码包还没搭好就先去做 12.2 再回来。【动手框】① 在哪执行你工程的main/motor_control.cpp改文件之后回到 l298n 工程根目录的 IDF 终端敲命令② 改什么、敲什么在init()里找到以if (!s_ledc_fade_installed) {开头的整块 fade 安装正确位置在通道配置之后把整块挪到ledc_timer_config_t timer_cfg {};之前——还原当年装错顺序的错误然后idf.py -p COM3 build flash monitorCOM3 换你的端口③ 预期看到崩溃前照常有一行I (xxx) l298n: L298N 直流电机演示启动——app_main 的开场日志打在 init() 之前所以一定能看到紧接着“就绪:” 日志永远不出现取而代之Guru Meditation Error: Core 0 paniced (LoadProhibited). Exception was unhandled. Core 0 register dump: PC : 0x420123a4 PS : 0x00060830 A0 : 0x800d1e9c A1 : 0x3fcee3d0 下面还有十几行寄存器是标准的案发现场快照此处节选略过 SAR : 0x0000001e EXCVADDR: 0x00000000 Backtrace: 0x420123a4:0x3fcee3d0 0x4037d4a2:0x3fcee3f0 0x4200f6b8:0x3fcee420 ELF file SHA256:这个值每次重新编译都会变 Rebooting...注意打印完回溯会自动重启Rebooting...就是重启预告重启后再崩一次日志从头循环刷屏——Guru Meditation ≠ 板子坏了第 6 章就说过。两个读法细节Backtrace 第一组的地址:栈指针就是寄存器表里的PC和A1可以互相对照你看到的地址和上面这组一定不相同固件不是同一份类型 EXCVADDR0对上就够了。电机完全不运动、崩溃也发生在任何硬件动作之前所以这个实验不必接驱动板和电机开发板单独插 USB 就能做。④ 没看到照常打出就绪没崩 → 安装块没真正挪到定时器配置之前检查位置monitor 乱码刷屏 → 波特率/端口问题回 2.11flash 失败 → 端口被别的 monitor 占用或按住 BOOT→点按 EN→松 BOOT手动进下载模式第 2 章三步。接下来就是 11.6 六步的跟做monitor 已经自动把 Backtrace 翻译好了11.5 说的便利三个地址的函数名与 11.6 那次是同一族——ledc 驱动内部函数 ←ledc_fade_func_install←DCMotor::init你也可以把手上最新 build 的 .elf 拿去跑 addr2line11.5 的命令照样翻得动——因为你烧的就是这份固件。这恰好和 11.6 括号里的陷阱互为镜像新日志配新 .elf 能翻旧日志只能配旧 .elf所以才要“每次发布前备份 .elf”11.5。做完把整块挪回原处重烧“就绪”日志回来实验闭环。11.7 其他崩溃类型类型机制常见原因LoadProhibited读了禁止的地址空指针、悬垂指针指向已归还内存的指针像攥着退掉的房卡StoreProhibited写了禁止的地址越界写、只读区写IllegalInstruction执行了非法指令栈坏 → 跳到垃圾地址Stack canary栈溢出检测递归/大局部变量Task watchdog任务饿死死循环/优先级反转第 13 章看门狗的原理、怎么喂狗、怎么避免饿死第 13 章有专门一节。11.8 调试流程背下来1. 看日志是否有前因 2. 看崩溃类型 EXCVADDR 3. addr2line 翻译 Backtrace 所有地址 4. 还原调用链找我们自己的代码层 5. 想清楚为什么空指针顺序越界 6. 修复 → 重编译 → 烧录 → 验证优化等级太高导致回溯不准时先改 -Og 重编译再查。11.9 常见问题速查问题方法固件太大-Os 关组件 别用 double崩溃看不懂类型 → EXCVADDR → addr2line翻译出系统库往调用链上层找自己的代码换 -O 就不崩未定义行为用 -Og 查build 目录被删重编译可恢复构建但旧崩溃地址从此无法翻译——每次发布前备份 .elf11.511.10 想一想 小测验想一想为什么 -O2 下 Backtrace 可能不准EXCVADDR0 说明什么请用访问权限解释 LoadProhibited。排查崩溃的完整步骤是什么小测验当前固件大小A. 172368 B. 162288 C. 176336LoadProhibited 的含义是A. 非法读 B. 非法写 C. 非法指令翻译崩溃地址用什么工具A. addr2line B. esptool C. idf.py size想固件最小用哪个优化11.11 本章总结体积-Os 影响最大size-components/files定位大头崩溃 非法操作触发 panicLoadProhibited 地址 0 空指针Backtrace 调用链addr2line 用 DWARF 调试信息翻译地址方法论类型 → 地址 → 调用链 → 想清楚 → 修 → 验证。下一章把全部知识串起来完成综合实战。
本章是工程能力章①固件体积怎么优化含本书真实账单②崩溃Guru Meditation到底是什么机制③用 addr2line 把崩溃地址翻译成代码行的完整方法含本书真实案例fade 安装顺序错误的崩溃排查全过程。11.1 体积账单先看我们项目的真实数字idf.py size当前发布版text data bss dec hex 118639 53598 362939 535176 82a88段大小存放含义text118639 BFlash代码指令data53598 BFlash 初值 SRAM 运行有初值数据bss362939 BSRAM大头是 IDF 预建的内存池/缓冲区不是我们的变量无初值数据最后两列dec/hex把 textdatabss 加在一起的总大小dec 是十进制、hex 是同一个数的十六进制写法——535176 0x82a88两种记数是同一个数第 0/1 章讲过互转。bin 大小烧录报告l298n.bin binary size 0x2a150 bytes 172368 B 0xd5eb0 bytes (84%) free 分区剩 876208 B体积变化记录我们的真实验证版本bin 大小原因初始 -Og176336 B基线不优化改 -Os162288 B优化等级省 14KBPSRAM 配置170768 B启动代码增加当前含 fade 修复172368 B最终相对 170768 增加约 1.6KB11.2 优化等级到底在改什么优化器是只改代码、不改语义的转换器。常见招式常量折叠x 100 * 2→x 200死代码删除if (0) {...}整段删内联小函数展开到调用处省压栈/跳转强度削减x * 2→x 1删除未用变量/函数没被引用的直接不进固件。选项目标体积速度调试-O0无大慢最好-Og调试友好中中好-Os体积小中一般-O2速度大快差⚠️ 优化会影响崩溃回溯代码被重排/内联后PC 地址和源码行对不齐。先 -Og 查 bug发布再 -Os。11.3 减体积五招-OsCONFIG_COMPILER_OPTIMIZATION_SIZEy省得最多关不需要的组件menuconfig 里蓝牙/WiFi/调试组件按需关别用 double浮点库整体很大printf(%f)等日志等级 INFODEBUG 字符串不进固件定位大头idf.py size-components、size-files找出最占地方的。11.4 崩溃机制Guru Meditation 是什么芯片检测到非法操作 → 进入panic恐慌状态Guru Meditation Error: Core 0 paniced (LoadProhibited)恐慌来源底层CPU 执行了禁止的访存读/写地址越界、访问保护区域内核级异常栈溢出、非法指令软件主动 abort如 ESP_ERROR_CHECK第 6 章。LoadProhibited的机制地址空间被分成很多区各自有访问权限。CPU 去读一个不允许读的地址如 0x00000000或未映射区→ MMU内存管理单元芯片里查这个地址准不准访问的门卫/总线保护→ 异常 → panic。LoadProhibited EXCVADDR: 0x00000000 访问了地址 0 大概率空指针指针的值是 0解引用它Backtrace回溯怎么读Backtrace: 0x4200942f:0x3fca0000 0x4037c123:0x3fca0010 0x42000056:0x3fca0030格式地址:栈指针依次排列第一个是当前卡住的位置后面是“谁调用了它”调用链。栈指针帮我们确认每一层的栈帧栈帧每次函数调用在栈上占用的那一格装着返回地址和局部变量。11.5 addr2line把地址翻译成代码行原理.elf 里带调试信息DWARF记录每条指令对应源码哪一行。addr2line 用地址查这张表。xtensa-esp32s3-elf-addr2line.exe-ebuild\l298n.elf-f-C0x4200942f-e指定 .elf必须有调试信息别删 build-f显示函数名-CC 名字还原成可读形式。在哪跑IDF 终端跑过 export 的窗口2.3提示找不到命令就是工具链没进 PATH先执行 export 再试。习惯每次发布前备份 .elf——把build\l298n.elf复制一份、按固件版本改名存档。旧崩溃日志只有配对的那份 .elf 才翻得动build 一删就永远翻不出来了11.9 有对应的坑。更省事的路idf.py monitor会在崩溃发生时自动把 Backtrace 里的地址翻译成函数名和源码行打印出来日常排查直接看 monitor 输出就行addr2line 是用来理解原理和处理离线日志的。11.6 真实案例fade 顺序崩溃的全排查过程症状第 7 章坑 2Guru Meditation Error: Core 0 paniced (LoadProhibited) EXCVADDR: 0x00000000 Backtrace: 0x4200942f:0x3fca0000 0x4037c123:0x3fca0010 0x42000056:0x3fca0030排查步骤完整方法演示读类型LoadProhibited 非法读EXCVADDR0 空指针翻译 3 个地址addr2line0x4200942f → ledc_ll_get_fade_end_intr_addr ledc 驱动内部 0x4037c123 → ledc_fade_func_install 我们调用的安装函数 0x42000056 → DCMotor::init 我们的代码注意这些地址来自修复前那次崩溃时的固件代码改过之后重新编译当前 build 里同样的行号/地址已经对不上了——翻译历史崩溃日志时必须用产生该日志的那一份 .elf别拿最新 build 去翻旧地址。看调用链DCMotor::init → 调用 ledc_fade_func_install →内部访问通道对象表——表还是空的 → 空指针原因install 放在 timer/channel 配置之前修复把ledc_fade_func_install(0)移到配置之后验证重编译 → 烧录 → 日志正常。方法论翻译地址 → 看调用链 → 想为什么访问空/非法地址 → 修 → 验证。不要瞎试。11.6b 动手实验亲手复现一次崩溃再亲手翻译它光读一百遍不如亲手崩一次。这个实验把 11.6 的案例故意重演一遍前提是你手上已有完整工程8.6 全文复现的motor_control.*两个文件 12.2 的main.cpp也可用随书源码包还没搭好就先去做 12.2 再回来。【动手框】① 在哪执行你工程的main/motor_control.cpp改文件之后回到 l298n 工程根目录的 IDF 终端敲命令② 改什么、敲什么在init()里找到以if (!s_ledc_fade_installed) {开头的整块 fade 安装正确位置在通道配置之后把整块挪到ledc_timer_config_t timer_cfg {};之前——还原当年装错顺序的错误然后idf.py -p COM3 build flash monitorCOM3 换你的端口③ 预期看到崩溃前照常有一行I (xxx) l298n: L298N 直流电机演示启动——app_main 的开场日志打在 init() 之前所以一定能看到紧接着“就绪:” 日志永远不出现取而代之Guru Meditation Error: Core 0 paniced (LoadProhibited). Exception was unhandled. Core 0 register dump: PC : 0x420123a4 PS : 0x00060830 A0 : 0x800d1e9c A1 : 0x3fcee3d0 下面还有十几行寄存器是标准的案发现场快照此处节选略过 SAR : 0x0000001e EXCVADDR: 0x00000000 Backtrace: 0x420123a4:0x3fcee3d0 0x4037d4a2:0x3fcee3f0 0x4200f6b8:0x3fcee420 ELF file SHA256:这个值每次重新编译都会变 Rebooting...注意打印完回溯会自动重启Rebooting...就是重启预告重启后再崩一次日志从头循环刷屏——Guru Meditation ≠ 板子坏了第 6 章就说过。两个读法细节Backtrace 第一组的地址:栈指针就是寄存器表里的PC和A1可以互相对照你看到的地址和上面这组一定不相同固件不是同一份类型 EXCVADDR0对上就够了。电机完全不运动、崩溃也发生在任何硬件动作之前所以这个实验不必接驱动板和电机开发板单独插 USB 就能做。④ 没看到照常打出就绪没崩 → 安装块没真正挪到定时器配置之前检查位置monitor 乱码刷屏 → 波特率/端口问题回 2.11flash 失败 → 端口被别的 monitor 占用或按住 BOOT→点按 EN→松 BOOT手动进下载模式第 2 章三步。接下来就是 11.6 六步的跟做monitor 已经自动把 Backtrace 翻译好了11.5 说的便利三个地址的函数名与 11.6 那次是同一族——ledc 驱动内部函数 ←ledc_fade_func_install←DCMotor::init你也可以把手上最新 build 的 .elf 拿去跑 addr2line11.5 的命令照样翻得动——因为你烧的就是这份固件。这恰好和 11.6 括号里的陷阱互为镜像新日志配新 .elf 能翻旧日志只能配旧 .elf所以才要“每次发布前备份 .elf”11.5。做完把整块挪回原处重烧“就绪”日志回来实验闭环。11.7 其他崩溃类型类型机制常见原因LoadProhibited读了禁止的地址空指针、悬垂指针指向已归还内存的指针像攥着退掉的房卡StoreProhibited写了禁止的地址越界写、只读区写IllegalInstruction执行了非法指令栈坏 → 跳到垃圾地址Stack canary栈溢出检测递归/大局部变量Task watchdog任务饿死死循环/优先级反转第 13 章看门狗的原理、怎么喂狗、怎么避免饿死第 13 章有专门一节。11.8 调试流程背下来1. 看日志是否有前因 2. 看崩溃类型 EXCVADDR 3. addr2line 翻译 Backtrace 所有地址 4. 还原调用链找我们自己的代码层 5. 想清楚为什么空指针顺序越界 6. 修复 → 重编译 → 烧录 → 验证优化等级太高导致回溯不准时先改 -Og 重编译再查。11.9 常见问题速查问题方法固件太大-Os 关组件 别用 double崩溃看不懂类型 → EXCVADDR → addr2line翻译出系统库往调用链上层找自己的代码换 -O 就不崩未定义行为用 -Og 查build 目录被删重编译可恢复构建但旧崩溃地址从此无法翻译——每次发布前备份 .elf11.511.10 想一想 小测验想一想为什么 -O2 下 Backtrace 可能不准EXCVADDR0 说明什么请用访问权限解释 LoadProhibited。排查崩溃的完整步骤是什么小测验当前固件大小A. 172368 B. 162288 C. 176336LoadProhibited 的含义是A. 非法读 B. 非法写 C. 非法指令翻译崩溃地址用什么工具A. addr2line B. esptool C. idf.py size想固件最小用哪个优化11.11 本章总结体积-Os 影响最大size-components/files定位大头崩溃 非法操作触发 panicLoadProhibited 地址 0 空指针Backtrace 调用链addr2line 用 DWARF 调试信息翻译地址方法论类型 → 地址 → 调用链 → 想清楚 → 修 → 验证。下一章把全部知识串起来完成综合实战。
