简介展讯平台软件调试是保障展讯芯片移动设备稳定运行的重要技术环节这份2021—2022年收藏的图文资料定位于嵌入式工程师与手机软件调试人员的学习参考。内容系统梳理了展讯方案的核心调试工具链Dloader负责程序下载、端口选择与打包文件制作NVEditor支持NV参数读写、擦除与下载Channel Server作为工具与手机通信的中介负责消息转发与字节序转换Logel提供实时诊断、Trace分析和Assert信息收集Phone Tester用于读写内存/寄存器、RF校准及Audio设置DSP Log则在开启NV对应选项后抓取数字信号处理器运行日志。文档还介绍了LOG打印与ASSERT断言的常见调试方法全文图文对照、步骤清晰。资源包由1个DOC格式文档组成整体大小约70KB轻量便于查阅。目前已有114人学习/下载对刚接触展讯平台或想系统化理解其调试工具链的开发者而言是一份低门槛的入门与排错参考。 搞展讯平台调试这行当手里没几份像样的“压箱底”资料是真不行。我翻到一份“精品资料2021-2022年收藏展讯平台软件调试介绍图文..doc”这名字一眼就知道是当时整理的老货但现在看依然很能打。展讯平台现在叫紫光展锐在国产手机、物联网模组、车机方案里遍地都是尤其是那些出货量巨大的4G功能机和入门智能机基本都被展讯公板方案包圆了。做这块的软件调试跟高通、联发科的路子有相通的地方但工具链和底层逻辑完全是另一套玩法。这篇就把我当时整理资料时的核心思路、调试环境的搭建、关键的log抓取与分析技巧还有那些年踩过的坑一次性说清楚。1. 展讯平台调试到底在调什么——先搞清楚对象再动手拿到任何一份调试资料第一件事不是看命令而是先建立对整个软件栈的认知地图。展讯平台跟高通不一样它没有那种高度封闭的“模块化信任链”而是更像一个大一统的RTOS加Linux混合体。调试的时候你面对的是Boot ROM、U-Boot、kernel、Android HAL、modem这几个层级每一层出问题表现的症状完全不同。1.1 从Boot到Modem四个层级的分工与故障边界展讯平台的启动链路通常是Boot ROM引导U-BootU-Boot拉起kernelkernel再启动Android或者纯Linux系统而modem基带部分则是独立的一个核跑在单独的CPU上通过共享内存方式和AP通信。这四个层级的分工是这样的Boot ROM固化在芯片里的只读代码主要负责初始化和加载下一级镜像。这一层出问题很少但一旦出问题就是变砖级别基本只能靠工具重擦。U-Boot负责内存初始化、分区表解析、镜像校验和加载。常见的“开不了机”、“卡在logo之前”大概率在这里。Kernel负责系统资源管理、设备驱动、文件系统挂载。kernel panic或者驱动加载失败直接导致系统起不来或者外设不工作。Modem独立运行电话、网络协议栈。它的崩溃往往表现为信号丢失、通话异常、数据断流而AP侧看起来一切都正常。调试时最忌讳“胡子眉毛一把抓”拿到问题先判断落在哪一层再决定用什么工具。比如“重启”和“死机”就是两个完全不同的调试方向前者可能要找modem的crash log后者则要抓kernel的panic栈。1.2 这份资料的核心价值在于“排查路径”我收藏的这份doc里头最有价值的部分不是某个具体的调试命令而是它把常见的故障现象和对应的排查路径做了梳理。比如“充电无反应”你会先测充电IC的寄存器还是先查kernel里充电驱动的probe是否成功不同顺序效率差三倍。这就是为什么我一直强调调试资料要读的是“思路”不是“操作”。操作是死的思路才能够在不同项目里复用。展讯平台的调试文档官方其实不少但大多写得零碎今天讲log明天讲工具缺少一条主线。而这份整理版精华就在于它用图文把“现象→模块→工具→结论”串了起来这也是我在多次实战中觉得最高效的调试模型。2. 调试环境的搭建驱动、工具链与连接方式展讯平台的调试环境搭建说难不难说简单坑是真不少。很多人第一次搞展讯方案卡在第一关就是USB驱动装不上或者工具连不上设备。这里我把环境搭建的核心要点单独挑出来讲这一块搞定后面调试就顺了。2.1 展讯刷机工具与USB驱动的选型逻辑展讯官方最常用的工具是ResearchDownload也就是大家俗称的RD和Flashtool。虽然展讯后续推出了统一工具链但老工程师手里基本都有好几个版本的备用工具。为什么因为每代芯片适配的工具版本有差异比如早年一些老芯片用低版本Flashtool刷不进去必须换特定版本。关于USB驱动这里有个非常关键的细节展讯的USB驱动有“下载模式”和“正常模式”两套驱动。刷机时设备进入的是下载模式常见PID/VID是0x1782此时需要安装的是展讯的Download Driver而正常开机后ADB使用的是标准Android USB驱动。如果混用就会出现“设备管理器里设备是正常的但Flashtool就是识别不了”。我的建议是装驱动前先在设备管理器里看端口或者USB设备的状态把未知设备识别出来手动指定驱动路径。展讯的驱动包通常自带几个子目录分别对应不同的PID/VID千万不要图省事一键安装完就不管了很大概率是装了个寂寞。另外如果是新出的芯片需要用新版本驱动老驱动即使硬件ID匹配也可能在下载阶段中断。2.2 串口与ADB两条腿走路刷机是底层操作日常调试更多用的是串口和ADB。展讯平台和大多数嵌入式平台一样保留了一路调试串口通常由UART0承担通过此口可以输出完整的U-Boot和kernel启动log。这路串口在板子上一般会引出来没有引出来的话就需要开发板上的调试座子转接。串口调试的波特率各厂家不一定相同展讯常见的是115200但一些平台早期在U-Boot阶段用的可能是921600。如果遇到串口输出乱码先别急着怀疑硬件先把波特率从高到低轮一遍。我碰到过一次U-Boot阶段用115200是乱码换到921600就正常了当时还以为是板子坏了折腾了好一阵。ADB用于Android层面的调试正常开机后可以用adb shell、adb logcat抓取上层日志。需要留意的是展讯平台在user版本量产版本上默认可能关闭ADB root权限如果要做深度调试需要先刷成debug版本或者userdebug版本固件。这算是展讯平台上常见的“第一次接触就卡住”的点。3. 核心调试手段与关键路径调试手段这块我分两块讲一是log的抓取和分析二是从log里定位问题的路径。展讯平台有一个好处它的log体系相对完整从AP到modem都有对应的log输出关键看你会不会抓、怎么抓。3.1 Log抓取从kernel log到modem log展讯平台常见的log类型包括Kernel log通过dmesg或串口获取记录内核崩溃、驱动加载失败、中断异常等信息。Android log包括main、system、crash等buffer通过logcat获取用于分析上层应用崩溃和系统服务异常。Modem log使用展讯专门的抓取工具如Modem Log工具获取记录基带侧AT指令、网络注册、通话状态等。Mobile log综合log官方工具支持一键抓取所有log的打包包括CPU频率、温度、各进程状态等。我一直强调抓log最忌讳的是“只抓一种”。比如遇到信号不稳定你只抓了logcat里面可能只是Android上层在抱怨“信号不好”你却看不到是modem和基站之间的信令问题还是射频前端硬件问题。正确做法是同时抓取modem log和AP侧log并且记录出现问题的时间点这样后续分析时才能把两个层面的日志对应起来。展讯的log工具一般会自动打时间戳如果没有务必在操作时手动记录时间节点。没有时间对齐的log分析起来事倍功半。3.2 从log到结论三种常见场景的定位思路我在整理文档时特别总结了三个高频场景的定位路径场景一开机reboot。先看串口log是否能完整走完U-Boot和kernel启动流程如果每次都停在同一个位置基本可以断定是硬件初始化失败优先排查对应外设的供电和复位时序如果随机死机则要检查kernel panic栈和modem crash是否是关联触发。场景二系统无反应但电源正常。拿串口log看是不是kernel起来了但Android没有起来还是系统在反复重启。展讯平台这类问题很多源于modem启动失败导致系统服务无法正常拉起需要抓取modem log确认modem是否完成了初始化。场景三通话无声。这是软硬件交叉的典型问题。先抓modem log看通话状态机是否正常建立再看AP侧音频通路配置是否正确看音频dsp的log有没有报错。最高效的做法是在展讯的音频调试工具里打开音频通路监控看call-time时的数据流走向。4. 实操过程中踩过的坑与排查技巧干我们这行光看懂官方文档是不够的很多问题只有自己在项目里摔过跟头才能长记性。我就把我这些年实操中踩过的一些比较典型的坑列出来做个速查表给新人少走弯路的参考。4.1 常见失败场景速查表现象排查方向常见根因刷机时工具提示“Download Fail”检查USB驱动、换USB口、低格工具驱动PID/VID不匹配或工具版本过老串口log在U-Boot阶段乱码尝试切换波特率波特率配置与平台实际不符开机一直卡在logo抓U-Boot log看镜像加载阶段分区表损坏或内核镜像校验失败logcat为空或抓不到log确认平台版本是否debug版、log等级user版限制了log输出通话声音异常抓modem log和音频log结合分析音频通道配置被上层错误重写设备重启后无法被识别设备管理器查看PID/VID变化驱动被更新替换需要重新指定这个表我建议你直接打印出来贴工位上遇到问题先对着表过一遍能省掉不少来回试的时间。4.2 最容易被忽视的“log前准备”很多人抓到log才发现分析不了然后回头骂工具差。实际上大部分问题出在抓log之前的准备工作没做好。三个必须提前确认的事情时间同步AP侧和modem侧的时间基准是否一致。不一致的话后续对齐事件点会非常痛苦。log缓冲大小展讯工具默认的log缓冲很小跑几分钟就覆盖了老数据。我习惯于调大到10MB以上尤其抓modem log时。复现步骤的记录让测试同事尽可能详细地记录操作步骤精确到按键和操作间隔。没有复现步骤的log价值要打个五折。另外一个细节展讯log工具抓取的log文件名往往是乱码或者一串无意义的编号我习惯在抓取后立刻重命名为“日期_现象_编号”比如“0712_重启_01”。这个习惯在后期整理资料、回溯问题的时候帮助巨大。4.3 从官方文档找不到答案时怎么办我自己在展讯平台调试中遇到过不少官方文档里没有写的“野问题”。这时候最有效的办法不是去论坛瞎搜而是利用展讯的log工具里隐藏的一些调试入口。例如通过特殊的AT指令可以让modem进入工厂测试模式对射频、音频、充电等模块做底层诊断。这些指令官方文档一般不公开但集成在工具包的“debug命令手册”里。所以我建议做展讯调试的工程师把工具包里所有PDF、Excel、txt说明文档都翻一遍别看不上那些“内部参考”关键时刻是真能救命。另一个技巧是展讯平台的kernel里藏了很多debug节点可以通过/sys/class/debug/或者/proc/expo/这类路径访问到芯片内部的寄存器状态、温度、电压等实时信息。这些节点不常用但在排查“偶发性死机”“低温异常”等疑难杂症时往往能提供关键线索。5. 一个被反复问到的关键问题如何通过固件包快速判断平台与版本最后一个我经常被新手问到的点拿到一个BIN文件怎么快速判断它是展讯哪个平台、哪个版本这其实是个很实用的小技巧但很多人不知道。展讯的固件包通常是pac或者xml配多个bin里会有一个版本信息文件或者头部信息可以通过hexdump工具打开其中一个img文件搜索类似“UNISOC”“SPRD”“UMS”“TGL”之类的字符串来粗略判断平台。有一个比较实用的做法用strings命令直接打印二进制文件里的可读字符串比如Linux内核镜像通常能看到编译时间、源码仓库信息、gcc版本号。有了这些信息再配合展讯工具里的版本号对照表就能判断固件是从哪条分支编译出来的。这在分析“为什么别人那个版本没问题我这个版本有问题”的时候特别管用。另外很多展讯方案的量产固件默认是开启secure boot的此时抓log的限制会多一些。如果发现部分调试指令无法执行先排查是不是secure boot状态的影响不要一股脑往工具问题上靠。了解平台的安全特性也是调试工作的重要一环。展讯平台这套调试方法说穿了就是“硬件基础、软件路径、log思维”三位一体。很多新人上来就想着记命令、背工具但实际上成熟的调试人员脑子里装的是一张“问题地图”现象出来先划分层级再选工具最后用log验证结论。2021到2022年整理的这些资料虽然时间过了两三年但底层逻辑没变展讯平台的项目如今依然活跃掌握这套调试思路起码能让你在接手任何一款展讯方案时心里更有底。本文还有配套的精品资源点击获取