Sensor调试实战：用QXDM抓取ADSP日志定位传感器数据异常的关键技巧

刚开始做Sensor调试那阵子最让我头疼的不是驱动代码本身而是问题根本复现不出来。板子拿在手里上层App偶尔报个传感器无数据logcat里干干净净HAL层看着也正常sensor节点都建出来了可就是数据不更新整个现象像幽灵一样定位起来极痛苦。后来有老同事提点了一句你QXDM挂上拿ADSP日志看看不就清楚了那一刻我才反应过来Sensor链路里真正的处理方不在AP侧而在ADSP这颗协处理器的固件里AP侧看到的往往只是结果不是原因。QXDM抓ADSP日志配合QsensorTest做设备侧验证这两件事组合起来基本覆盖了Sensor调试里九成以上的问题场景。前者解决的是底层固件到底在干什么、为什么不出数据后者解决的是从HAL到sensor芯片这条完整链路是否真的通了。这篇就把我实际调试中反复用到的5个关键技巧整理出来每个都踩过坑写出来给同样在Sensor这片折腾的人参考。1. 先理清调试思路Sensor出问题为什么必须抓ADSP日志1.1 Sensor调试和普通驱动调试的本质区别很多刚转来做Sensor的同事会习惯性用普通外设驱动的思路来调sensor打开logcat看HAL报错或者拿GPIO量中断这当然有作用但往往定位不到根因。原因其实很直白在高通平台上传感器数据通路并不是AP直接读寄存器而是AP侧的sensor HAL通过FastRPC调用把请求下发到ADSPADSP里跑着一整套Sensor Low Power Island的固件框架包括sensor manager、registry、算法引擎然后由ADSP通过SNOC、QMI或共用内存把处理完的数据回传给AP。也就是说你看到的那个节点存在但数据不动真正卡住的位置可能在ADSP固件比如说sensor的寄存器配置没进去、初始化时在registry里找不到这个传感器、算法引擎把数据拦下来了、电源状态切错了。这些信息在AP侧logcat里几乎不会出现只有把ADSP侧的diag日志拉出来才能看到固件内部的执行轨迹。所以调试Sensor的第一步认知就是AP侧日志负责定位链路有没有通到ADSPADSP侧的QXDM日志负责定位ADSP固件到底在哪一步出了问题两者缺一不可。1.2 QsensorTest在这条链路里的角色QsensorTest是高通提供的一个传感器验证工具一般跑在手机/板卡的系统侧它做的事情是从HAL层直接去枚举sensor、订阅数据、查看曲线。它解决的问题是在硬件、固件、HAL、权限这一整条链条里系统侧到底能不能正常拿到数据。如果QsensorTest都拿不到数据那基本可以排除应用层的问题接下来要么查HAL对接要么往下钻ADSP日志如果QsensorTest数据正常但自己的App拿不到那问题就往权限、sensor服务、应用框架方向走。我个人的调试习惯是复现问题之前先把QsensorTest挂上把现象量化一遍再决定要不要上QXDM。如果QsensorTest能复现异常说明链路从硬件到HAL都是存疑的必须抓ADSP日志深入如果QsensorTest正常那就把重点放在应用层和系统服务层。这个先后顺序能省掉大量无意义的抓log时间。1.3 我常用的工具组合与适用场景工具组合方面我通常准备三样QXDM抓ADSP侧DIAG日志、QsensorTest系统侧传感器验证、串口或者ADB抓内核日志和HAL日志。具体用哪一组取决于现象现象分类首选工具关注重点sensor完全不出数据QXDM QsensorTestADSP初始化流程、registry枚举结果数据不更新或数值冻结QXDMsensor中断触发、FIFO轮转、power state数据有输出但明显不准QsensorTest QXDM校准参数、原始数据和算法输出的对比偶发丢数据或系统休眠唤醒后异常QXDM 内核日志ADSP suspend/resume、sensor的reset流程调试的时候别急着上来就抓log先把问题归类再选工具效率会高很多。2. 关键技巧一QXDM抓ADSP日志的正确姿势2.1 连接前必须处理的端口与驱动问题QXDM抓ADSP日志首先得让电脑能够通过DIAG口和手机通信。很多人第一步就卡住了连上设备后QXDM端口列表里空空如也或者显示乱码。我的建议是先把这四件事按顺序做一遍第一步确认驱动。高通板卡连接电脑后设备管理器里应当出现Qualcomm Diagnostics Interface或者Qualcomm HS-USB Diagnostics之类的设备端口。如果只显示COM口但没有Qualcomm字样说明驱动没装对需要重新安装QPST或者单独的DIAG驱动。第二步激活DIAG端口。很多量产机上DIAG端口默认是关闭的需要先在ADB侧执行setprop persist.vendor.diag.adb.debug 1或者通过adb root后打开对应的DIAG配置节点。这一步不做的话QXDM什么都扫不到。第三步选对端口。QXDM连接时不要看到有COM口就随便选要看端口描述里带不带DIAG。若有两个DIAG口一般是AP侧和ADSP侧各一个Sensor调试要选ADSP侧的DIAG口。区分方法很简单接上后执行adb devices和QXDM扫描结果对照一般ADSP侧DIAG口的描述里会多一个ADSP或DSU字样。第四步关闭占用。Windows下如果串口工具比如SecureCRT、串口助手占用了同一个COM口号QXDM会一直连不上。排查时先把所有串口工具关掉再重新扫描端口。2.2 ADSP日志过滤配置的核心选项QXDM连上了以后关键动作是配置要抓哪些LOG包。默认配置下ADSP日志输出是很有限的你不打开对应的Filter抓到包全是AP侧的OS LogsADSP的内容一个都见不着。Sensor调试时我最常用的配置组合是这样在View - Filter and Export里选择ADSP相关的LOG包。重点关注的几类SNSSensor、SNS_ASYNC、SNS_SMGR、SNS_SM、SNS_REGISTRY。不同版本的QXDM里命名可能略有差异但只要涉及到SNS前缀的基本就是sensor框架相关的日志。另外一个需要勾上的是SNOC相关的log因为sensor中断和FIFO flush事件会通过SNOC通报AP侧这部分日志对定位有事件但没数据的故障帮助很大。如果想要sensor算法层的详细执行轨迹可以去把每个具体sensor模块的debug级别拉高。这个通常通过向ADSP侧下发debug指令或者修改固件里的log level宏来实现不同平台做法不太一样但效果是让固件把每一步执行细节都打出来。配置好Filter以后要看实时log流是否在滚动。如果滚动的都是无关的OS日志没有SNS内容先别急着复现问题把配置检查一遍确认ADSP侧的log channel是通的。2.3 抓log过程中的buffer与保存细节很多人在复现问题的时候会遇到一个尴尬情况现象出来了但QXDM里log早就被冲掉了或者中间丢了一段关键信息。这几种做法能有效减少这种问题第一复现问题前先点Start Logging而不是Start Capture。前者会将log流持续写入文件后者只是开启屏幕显示两者有区别。我们需要的是持续记录到文件方便回溯。第二ADSP日志的buffer是按包数算的若配置的LOG包过滤过窄会漏掉一些不相关但关键的上下文若过滤过宽buffer很快被无关日志占满。实际中我会配置一组基础包传感器包基础包保持很小的量传感器包全开这样既不会漏关键信息也不会因为刷屏太猛丢数据。第三抓长时间日志时用Rotate功能按文件大小自动切割一般设为50MB或100MB一段。这样如果现场复现耗时很长文件也容易管理后期用文本工具分析时也不会因为文件太大卡死。提示现场抓log时手机和电脑之间最好用短一点的USB线数据线越长高速DIAG模式下越容易出现断流一断流前面的log就白抓了。我踩过好多次这个坑线材那点钱不能省。2.4 抓完日志后的初步处理流程日志抓到本地以后我会习惯性做一个快速预筛动作把保存出来的文件直接用文本编辑器打开搜索SNS或者sensor关键字看看当前这个场景下ADSP侧有没有对应的事件输出。如果搜出来有大量SNS日志那说明ADSP固件确实在跑问题就集中到具体逻辑如果搜出来几乎没有SNS相关内容那问题很可能出在AP侧没有把sensor请求真正下发到ADSP或者固件压根没感知到这个sensor的访问。这个判断在调试中能少走很多弯路。3. 关键技巧二ADSP日志怎么读才算读明白3.1 先分清ADSP日志里常见的模块缩写刚接触QXDM里ADSP日志的人很容易被满屏的缩写给劝退。比如SNS_SMGR、SNS_SM、SNS_ASYNC、SNOC_CFG、QCOR单看缩写根本不知道谁是谁。这块我整理了一个速查表给团队里新人用效果很不错模块缩写全称/含义调试关注点SNS_SMGRSensor Manager传感器总管传感器枚举、请求管理、电源状态切换SNS_SMSensor Manager子模块负责单个sensor管理单个sensor的初始化、使能、采样配置SNS_ASYNC异步事件处理模块中断事件、异步消息处理SNS_REGISTRY传感器注册表sensor是否有正确注册、属性是否完整SNS_ALGO算法框架算法初始化、算法输入输出QCOR / QDSP通用呈现、DSP核心日志全局状态、错误上报、重启原因SNOCSensor Network On ChipAP与ADSP之间的通信状态读日志的时候遇到这几种模块就大致知道该往哪个方向查了。比如日志里SNS_REGISTRY报错多半是sensor的注册表项配置不对SNS_ASYNC报超时多半是中断或者请求没有按时处理。3.2 定位问题核心搜索与上下文分析ADSP日志量很大不可能逐行去读我的做法是先搜错误级别关键字。常见的严重级别标识有FATAL、ERROR、WARN先把这些行全部捞出来看一遍这时候往往就已经能锁定大概方向了。如果错误关键字没有收获说明问题不一定体现在显式错误里可能是逻辑上的静默失败。这时就要靠模块关键字配合时间戳来追踪。比如我在调试一次加速度计不出数据的问题时现象是上层一直拿不到数据error级别日志也没有。我就顺着时间戳去看SNS_SMGR和SNS_SM的事件序列发现在初始化之后SNS_SM一直处于IDLE状态压根没有进入ACTIVE状态说明请求下发到了manager层但单个sensor的处理状态没有切对。后来查固件代码发现是sensor的enable配置漏了一个采样率的宏导致状态机一直卡在初始化阶段这个就属于光看error日志很难发现的问题。再补充一个经验ADSP日志里的时间戳单位通常是毫秒级别后面还跟着一个计数器你可以先找到日志开头自己打的特殊标记比如在HAL侧打印一条带时间戳的log同时在ADSP日志里搜索sensor使能的时间点把两边的时间轴先对上后面分析时序问题会省很多事。3.3 别忽视SNOC和中断相关的日志Sensor数据链路里有一个很常见的日志看起来正常但实际没数据的场景。实际上数据路径可能根本没通。这种问题靠sensor关键字搜不到反而要去看SNOC的日志。SNOC负责传感器网络在AP和ADSP之间的数据搬运如果SNOC里看到有FIFO empty或者reset之类的异常记录那说明ADSP算出的数据根本没有成功送到AP侧或者被snoc层的状态机给吞了。我在一次项目里就遇到过接近传感器在休眠唤醒后偶尔失效QsensorTest里能看到sensor节点但就是没有中断上来。后来翻了SNOC日志发现每次唤醒后都有一次SNOC RESET事件而reset过后sensor的事件订阅就丢了。问题根因指向ADSP在resume流程里没有重新把sensor的中断注册回来这属于固件流程的bug光在AP侧logcat里完全看不出来。4. 关键技巧三QsensorTest验证的正确打开方式4.1 测试前的状态确认很多人打开QsensorTest就直接点Sensor List发现列表里没有目标sensor就开始怀疑硬件挂错或者驱动没加载。其实这个判断太急了QsensorTest能枚举出的sensor列表依赖HAL层读到的注册信息而注册信息是否完整取决于ADSP固件里的registry是否配置好。所以QsensorTest前我习惯先快速跑一遍下面的检查先去看sensor list里是否存在目标sensor如果存在直接订阅数据看是否随着物理变化而更新这是最直观的判断很多情况下数据不同步是驱动采样配置问题而不是功能不回。若sensor list里压根没有这个sensor则需要回头去看ADSP日志中sns_registry的枚举结果或者HAL层的sensor_list配置文件。另外要特别提醒的是QsensorTest里看到的sensor name和手册上的sensor name可能不完全一样通常带平台前缀千万别因为名字对不上就断定没有这个sensor。4.2 数据观测与异常判断QsensorTest主界面会列出当前可用的sensor点击任意一个能看到实时数据曲线和数值。调试中我会特别关注以下几点第一数据是否随着物理运动变化。把板子/手机拿在手里做旋转、翻转、走动等动作观察数据是否跟随变化。如果数据一动不动优先怀疑硬件中断没有触发或者sensor在ADSP侧没有被正确使能。第二数据更新的频率是否合理。QsensorTest里可以看到上报频率如果设置了100Hz却只有10Hz的更新速度那多半是sensor的rate配置、FIFO配置或者HAL层的batch参数有问题。第三数值范围是否合理。加速度计静止时应该接近1g陀螺仪静止时应该接近0如果基值明显偏移就要考虑校准参数、零漂、或者硬件贴片问题。这四个维度基本能覆盖sensor功能层面的绝大多数问题。如果QsensorTest显示一切正常但应用层还是拿不到正常数据那问题就比较集中了要么是sensor服务缓存数据的问题要么是应用没有正确注册监听。4.3 用QsensorTest主动制造复现条件QsensorTest不只是用来看的它还承担着一个重要职责主动制造复现条件。例如有些丢数据问题只有在高频率上报屏幕熄灭休眠唤醒组合操作后才出现手动去操作手机非常难稳定复现把QsensorTest设置成连续高频记录配合脚本做息屏亮屏操作就能把复现概率从偶尔一次提升到几乎必现。我常用的复现场景组合包括高频采样持续5分钟看是否有中断停摆高频采样中反复开关屏幕看sensor状态是否正确恢复切换sensor的rate配置从低到高看数据是否出现断层以及多sensor同时开启看通道之间是否互相干扰。这些操作在QsensorTest里都能直接完成比写App去测要快得多。4.4 QsensorTest数据与ADSP日志的联动验证这里说一个我特别喜欢用的组合招QxDM挂着ADSP日志QsensorTest开着数据曲线然后同时操作。当QsensorTest界面上数据出现更新异常的那一瞬间立刻在ADSP日志里去看该sensor的采样请求状态、FIFO状态、数据回调状态。这种联动方式能非常直观地还原上层请求到了下层执行的完整链路。比如一次接近传感器误触发的排查中我开着QsensorTest观察接近值同时抓ADSP日志。界面上看到接近值在没有遮挡的情况下突然从far跳到near与此同时ADSP日志里对应sensor的采样请求没有任何变化说明这个值变化不是来自采样请求而是来自算法侧比如防误触算法主动上报的事件。顺着这条线查下去才发现是算法参数里把靠近判定阈值设得太激进了误判触发。这种场景如果只看QsensorTest数据最多只能确认现象存在根本定位不到算法层。5. 关键技巧四日志时间轴对齐别被假象带偏5.1 让各路日志用同一个时间基准Sensor调试中日志来自多个地方AP侧logcat、ADSP侧QXDM日志、内核日志、QsensorTest记录。问题是一旦某个环节出现延迟或超时时间不对齐很容易做出错误判断。我现在每到一个调试项目第一件事情就是把各路日志的时间基准统一起来。对logcat开启时间戳输出这个默认就有对内核日志确认dmesg时间戳是相对boot的时间还是wall clock对ADSP日志用QXDM抓取时记录的起始时间对QsensorTest它会把测试过程的本地时间打出来。这四个时间源要对照分析最稳妥的办法是在实验最开始统一做一个时间打点动作比如同时看表在logcat、内核日志、QXDM中记录下同一秒的标志并同步按下QsensorTest的某个按钮这样后续所有日志都以这个打点时刻为0基准来偏移分析。5.2 事件复现的记录节奏还有一点关于复现节奏。很多人复现问题的时候动作一大套从解锁到打开App到点击按钮全在空中一气呵成。等到分析日志时才发现根本对不上是哪个动作触发了异常。我现在要求自己复现问题的时候动作拆细每个动作前停顿2到3秒。比如打开QsensorTest-停2秒-订阅数据-停2秒-息屏-停3秒-亮屏-停2秒-观察数据这样每段日志之间都有明确的时间间隙分析时一看时间戳就能精确定位是哪个动作前后出了问题。5.3 在HAL层加临时打点精准缩小范围如果问题比较顽固光靠时间戳对齐还不够我会在HAL层临时加一些打点日志把关键路径上的时间打出来这些打点可以明确看出来sensor是否成功订阅、数据回调是否触发、延迟了多少毫秒。这类打点在发布前记得删掉不然会刷屏。打点之后结合QXDM里ADSP侧对应的sensor使能、采样请求日志基本能把问题范围缩小到三个层面之一请求根本没到HAL应用层问题、请求到了HAL但没到ADSPHAL到ADSP通信问题、请求到了ADSP但数据回不来ADSP固件或者数据通路问题。这三个层面分清楚后面的工作就是定向排查的事情了。6. 关键技巧五避坑清单与排查实录6.1 QXDM连接类问题速查现象常见原因处理建议QXDM扫描不到端口驱动未装/DIAG未打开重装DIAG驱动确认diag.adb.debug属性连接成功后无日志过滤配置不对/选错端口确认选了ADSP侧DIAG口检查LOG包过滤项抓取过程中断流USB线材质量差/端口不稳定更换短线降低DIAG传输速率日志刷得太快看不过来Filter配置太宽收紧过滤条件只保留SNS/SNOC相关LOG包保存的文件巨大未开启文件切割设置Rotate按文件大小切割6.2 ADSP日志无输出类问题实录最常遇到的坑是Filter配置里勾了SNS相关LOG包但抓出来的日志里完全没有SNS内容。第一次遇到时我也懵了好久后来发现是选了ADSP侧的Log Session但没有触发一次真实的sensor访问ADSP日志的部分模块是懒加载的平时不输出只有真正发生sensor请求时才会有日志。解决办法很简单把QsensorTest打开订阅一个sensor数据让sensor链路活起来ADSP日志就会开始滚动了。另一个坑是抓出来全是内核日志没有diag日志。这种一般出现在older平台或者固件版本较老的情况下需要在QXDM的配置里显式打开ADSP的Log Elaboration或者升级QPST到跟平台匹配的版本。6.3 QsensorTest异常类问题实录QsensorTest打开后提示sensor not available多数情况下不是sensor坏了而是HAL层的sensor list没有包含这个sensor。常见原因有三种一是HAL配置文件里没添加对应sensor的type和name二是ADSP固件里registry没有上传该sensor导致HAL枚举不到三是sensor的power supply或中断GPIO配置有问题导致固件初始化失败后没有把sensor信息上报给AP侧。处理顺序是先看HAL配置文件再抓ADSP日志查registry最后检查硬件配置和中断引脚状态。还有一个经验是QsensorTest出现数据跳变剧烈但日志和硬件都没问题。这种现象多与sensor的校准状态有关尤其是磁力计和陀螺仪这类需要动态校准的传感器。上电初期数据波动大其实是正常的等待几秒到几十秒让算法完成归零校准数据就会稳定下来。如果一直不稳定才需要怀疑硬件或者算法参数。6.4 一些我觉得非常有价值的调试心得最后说点个人体会。Sensor调试最大的难点是不确定性和隐性状态问题可能藏在AP侧、ADSP固件、硬件器件、算法参数、电源控制等多个环节而且很容易被表象正常误导。我踩过的不少坑都是因为只抓了一路日志就匆忙下结论后来用双通道、三通道日志对照分析才发现真正的触发条件。另外在开方案评审的时候我会建议硬件同事把sensor的中断GPIO和供电引脚单独引到测试点调试时可以直接用示波器量中断脉冲这比纯软件看日志判断硬件是否干活要高效得多。软件加示波器加日志三件套才能把Sensor调试这块真正玩明白。还有一个特别实用的习惯每次调试完一个问题把QXDM对应的Filter配置导出一份连同问题分析报告存到一个共享目录里。因为不同项目的ADSP日志Filter配置有很多相似之处下次遇到类似问题直接导入配置省去重新摸索的时间。尤其带团队的时候这套配置资产能让新人上手速度提升一大截。