Trace32抓不到Trace，很多时候不是单纯没点开窗口，而是链路里前面几层没有先对齐。Lauterbach官方资料把典型问题分得很清楚，一类是根本没有有效Trace数据，比如Trace口被别的IO复用、采样建立保持时间不够、目标频率过高；另一类是有数据但带宽不够，结果出现FIFOFULL、FLOWERROR或记录不完整。真正排查时，先把链路有效性和带宽余量拆开看，会比一上来乱改参数更快。

　　一、Trace32 Trace抓不到数据

　　Trace32 Trace抓不到数据，先不要只盯Trace.List是空的，更要先确认目标有没有把有效Trace真正送出来。官方训练资料和知识库都强调，外部Trace先要把目标侧Trace引脚和CoreSight基础设施配置对，再谈后续记录。

　　1、先查Trace口是不是被别的功能占了

　　官方把HARDERROR的首要原因之一直接写成trace port multiplexed with other IO functions，也就是Trace口还在复用成GPIO或其他接口。对Arm ETM场景，官方训练还明确把Enable TPIU pins放在基础步骤第一位，所以抓不到数据时，先看芯片有没有把TPIU或Trace引脚真正切到Trace功能。

　　2、再查CoreSight链路是不是配对了

　　如果芯片和基础设施已被TRACE32识别，软件通常会自动配置；若不是，就要先用SYStem.CONFIG.state/COmponents检查CoreSight组件链。这里如果ETM、TPIU、ETB或Funnel的配置关系不对，后面就算目标真在吐数据，主机侧也可能接不上。

　　3、然后核对PortSize和PortMode

　　官方训练写得很直接，ETM.PortSize决定目标到底有多少根TRACEDATA引脚可用于导出Trace包，ETM.PortMode则决定Formatter工作方式。PortSize填大了或填小了，都会直接影响解码；PortMode选错，也会让TRACECTL或空闲符号解释不对，最后表现成没数据或全是坏数据。

　　4、最后用错误类型反推原因

　　如果记录里出现HARDERROR，官方定义就是trace data is not valid，常见原因包括端口复用、采样失败、PowerTrace模块版本不对和目标频率过高；如果出现FLOWERROR，通常说明数据已经不再和目标代码一致。先用Trace.Find FLOWERROR/ALL这类命令把错误点找出来，再继续分析，会比盲看波形高效。

　　二、Trace32带宽与时钟设置怎么核对

　　Trace32带宽与时钟设置怎么核对，核心不是一味把频率拉高，而是先确认链路稳定，再判断当前Trace产生量有没有超过链路承载。官方知识库对FIFOFULL的解释非常直接，trace sources产生的信息超过了芯片Trace基础设施能处理的带宽时，就会丢包。

　　1、先看Trace时钟是不是已经到合理上限

　　官方建议非常明确，出现FIFOFULL时，先检查trace clock是否已经跑在目标支持的最高速率，并同时使用最大的port speed和width。也就是说，时钟核对不是只看CPU主频，而是看Trace基础设施本身有没有跑满。

　　2、再看JTAG或调试口时钟是不是拖了后腿

　　虽然Trace和JTAG不是同一条通道，但官方在高带宽DAP Streaming场景里给出了很直白的经验值，先把debug port type设成DAPWide，再把SYStem.JtagClock提到稳定前提下的最高值；120 MHz通常是较稳的起点，160 MHz可进一步提高吞吐，但前提是调试链路稳定。这个思路同样适合先核对调试链是不是已经成了瓶颈。

　　3、带宽不够时先减Trace源，而不是只加频率

　　官方给出的第二条解决思路，就是让trace sources发送更少的信息，例如关闭当前用不到的数据Trace或内部时序信息，或通过TraceEnable、TraceData、TraceON、TraceOFF之类过滤手段缩小输出范围。时钟和带宽已经接近上限时，减源通常比继续硬提频率更稳。

　　4、再用FIFOFULL和HARDERROR做复核

　　官方同时给了两类现象的定义，FIFOFULL代表带宽不足导致丢包，HARDERROR更偏向数据本身已失真。所以核对完宽度、时钟和过滤范围后，最好再看一次Trace里还有没有FIFOFULL和HARDERROR；如果FIFOFULL消了但HARDERROR还在，就说明问题更多是时序和信号质量，不只是带宽。

　　三、Trace32链路异常怎么收口

　　真正把问题收住，不是一次把所有参数全改掉，而是按固定顺序一点点排。Lauterbach官方的材料其实已经给出了一条很清晰的思路，先保证链路有效，再保证配置匹配，最后再压带宽。

　　1、先确认目标侧引脚和组件链是通的

　　也就是先查TPIU引脚是否启用，CoreSight组件有没有识别对，PortSize和PortMode是否匹配板级实际连线。前面这一步没对，后面调时钟基本不会真正见效。

　　2、再确认链路有没有坏数据

　　如果一开抓就出现HARDERROR，优先怀疑端口复用、采样时序、目标频率或硬件模块匹配问题；如果没有HARDERROR但有FIFOFULL，再转去带宽方向处理。这样能把“抓不到”和“抓不全”分开。

　　3、带宽侧先加宽再减源

　　先把PortSize、Trace clock、port speed和调试链吞吐提到目标允许范围，再看是否还要关闭数据Trace、内部时序信息或加过滤。这个顺序更接近官方给出的处理逻辑。

　　4、最后再评估是不是该换采集方式

　　如果外部Trace口本身就窄，或者板级信号质量始终不够，继续硬顶时钟往往收益不大。这时更应该回头评估onchip trace、缩减Trace源或其他更适合当前板级条件的方案，而不是一直在同一组参数里死磕。这个判断是依据官方对带宽瓶颈、链路稳定性和不同Trace基础设施能力的说明得出的。

　　总结

　　Trace32 Trace抓不到数据，先查目标有没有真正把有效Trace从引脚和CoreSight链路送出来，再查PortSize和PortMode是否匹配，最后用HARDERROR、FLOWERROR去定位问题层次。Trace32带宽与时钟设置怎么核对，重点则是先看trace clock、port width和JTAG调试口吞吐，再看是否需要缩减Trace源，最后用FIFOFULL是否消失来判断调整有没有真正生效。这样按层收口，通常比反复试频率更快。