简介：展讯平台软件调试是保障展讯芯片移动设备稳定运行的重要技术环节，这份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-Boot，U-Boot拉起kernel，kernel再启动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年整理的这些资料，虽然时间过了两三年，但底层逻辑没变，展讯平台的项目如今依然活跃，掌握这套调试思路，起码能让你在接手任何一款展讯方案时，心里更有底。
本文还有配套的精品资源，点击获取
