TRACE32快速入门：安装、硬件连接与首次halt避坑

简介：《劳特巴赫TRACE32快速入门》是一份面向嵌入式调试初学者与刚接触劳特巴赫调试器的工程师的入门手册，围绕TRACE32的软件安装、硬件环境搭建和软件启动三条主线展开，帮助读者解决环境配置不熟、目标板连接与识别困难等起步问题。压缩包内为1个PDF文件，约6.17MB，篇幅紧凑，便于按章节查阅。内容不仅覆盖安装包获取、Windows安装、JTAG/SWD连接、上下电顺序与设备识别确认，还补充了通过PowerView网络连接LA-3505、CPU列表中找不到目标芯片的排查思路以及命令行启动方法；对断点、内存查看、寄存器操作、数据跟踪等功能也有引导。已有6456人学习，适合作为调试环境搭建与基础操作的上手参考，也可为后续深入Trace功能、脚本和自动化调试打下基础。

1. 从插上调试头到第一次 halt：卡住的人比想象中多

劳特巴赫 TRACE32 调试器拆箱那一刻，多数人的第一反应是把 USB 线接上、双击图标、随便点个 Connect。结果弹窗报错，换成目标板 reset 也不行，再翻 CPU 列表，连自己那颗芯片的名字都搜不到。问题往往不在调试器本身，而是安装时没勾对应架构、上下电顺序反了、或者根目录那份config.t32被前一位同事改过。这份快速入门手册讲的就是这段最容易出问题的环节：安装包怎么挑、硬件链路怎么接、上下电按什么顺序、快捷方式和命令行启动差在哪、CPU 列表空白时往哪查。它不涉及 ARM 架构，也不讲断点原理，只解决「从零到第一次 halt 住」。适合刚接手调试器的固件工程师、要在多台机器复现同一套调试环境的团队，以及准备把 TRACE32 接进自动化流程的人。

2. 安装包怎么挑：光盘、完整包、增量包和四个平台勾选项

安装这一章决定了后面几天是否顺利。同样一份 TRACE32，用光盘镜像装和用官网增量包装，装出来的目录结构、pdf文档目录、驱动版本可能都不一样。手册把安装包拆成四种来源，实际选择时要看你现在是「空机器首装」还是「旧版本升级」，两种情况的正确操作完全不同。

2.1 四种来源的差异与选择逻辑

手册列出的四种获取方式各有适用范围：

选择逻辑其实很清楚：新机器从零开始，走完整安装包；已经有能用的旧版本、只是缺某颗新芯片的支持，走增量包。增量包最容易出问题的地方在于「覆盖」这两个字——它不是安装程序，没有依赖检查，也没有回滚，解压后直接把文件盖到原 T32 目录。盖之前把原目录压缩一份，出问题时能退回去。注册环节填的调试头序列号在调试头外壳标签上，注册之后有新版本发布会收到邮件提醒，这一点对长期跟芯片迭代的团队比较实用。

2.2 Windows 下的典型安装与平台勾选

Windows 下的入口是安装包根目录的setup.bat，双击后按向导走。大部分界面保持默认即可，真正决定后面能不能连上的是两处：安装路径和平台勾选。

安装路径这一项，我一般强制要求纯英文、无空格、层级不超过两级，例如D:\T32。带中文或空格的路径会让部分脚本的相对路径解析失败，表现为装完了但pdf目录打不开、或者启动时报找不到资源文件。这个坑在团队共用安装包时特别常见，因为默认路径往往落在用户名下面。

平台勾选是第二个关键点。典型安装（Typical Installation）之后会出现平台选择页，勾选项决定了安装目录里会放哪些架构的可执行文件和 CPU 支持库。手册给了一张对照表，实际使用时按目标芯片的内核来选：

勾错的表现不是装不上，而是装完打开对应快捷方式后，SYStem.CPU的下拉列表里找不到目标型号。这时不用重装整个软件，重跑一次setup.bat，把漏掉的架构补勾上就行。多勾几个架构不会带来明显的体积负担，但会让开始菜单里多出几组快捷方式，对只想调一个平台的人来说反而是干扰。

驱动安装步骤会弹权限确认，这一步必须给管理员权限，否则设备管理器里会出现带黄色感叹号的未知设备。最后一步询问是否注册，可以跳过，后面再补。

2.3 Linux 下的依赖与驱动安装

Linux 侧的差异主要在依赖包。手册以 Ubuntu 64 位环境安装 R.2020.09 为例，给出两条前置命令：

# TRACE32 PowerView 依赖的 Qt5 运行库 sudo apt-get install libqt5gui5 sudo apt-get install libqt5printsupport5 # 部分发行版还缺这些，按启动报错逐个补 sudo apt-get install libqt5network5 libqt5svg5

这两条只是起点。实际执行时判断缺哪个库的方法很直接：直接跑一次 PowerView，报错信息里会写明libQt5Xxx.so.x: cannot open shared object file，缺什么补什么。手册也明确说了「包括但不限于上面两个，根据具体 Linux 发行版本会有差异」，所以不要指望一套依赖命令通吃所有发行版。

装完依赖后进入光盘或安装包目录，执行安装脚本：

cd /media/cdrom # 或解压出来的安装包目录 sudo ./setup_linux.sh # 安装设备驱动需要 root 权限

两个细节值得记一下。第一，setup_linux.sh必须cd进目录再执行，用绝对路径直接调用会因为脚本内部的相对路径假设而失败。第二，只有安装驱动那一步需要sudo，日常跑 PowerView 不要用 root，否则config.t32和日志文件的属主会变成 root，下次普通用户启动时读不了配置，报出来的错误又和权限问题八竿子打不着。装完之后去安装目录看一眼结构：bin下按操作系统分目录放可执行文件，pdf下是完整文档，根目录有config.t32，这三处是后面所有操作的落脚点。

3. 硬件链路与上下电：LA-3505、μTRACE 的三种接法和一条固定顺序

软件装对了只是第一步，从 PC 到目标芯片中间还隔着主模块、调试线缆、目标调试口三段物理链路。任何一段接触不良或者上电时序错了，表现都是同一个「连不上」，很难从报错信息里区分。手册把这段拆成连接方式、上下电顺序、环境确认三步，按这个顺序走，能把问题范围缩小到某一段。

3.1 三种主模块的连接拓扑

不同型号的主模块支持的宿主连接方式不一样，这一条决定了你能不能做远程调试：

完整的物理链路是：PC → 主模块（PowerDebug）→ 调试线缆（Debug Cable）→ 目标板调试口。LA-3505 用 USB 连接时和 LA-3500 一样，插上就能识别；走网络时则要先把主模块的 IP 配好，PC 侧再按网络节点方式连接。μTRACE 系列体积小，一般直接挂在目标板旁边，只有 USB 一条路。

这里有个容易混淆的点：USB 口和调试口是两回事。USB 连的是主模块和 PC，负责传数据；调试线缆连的是主模块和目标芯片的 JTAG/SWD 口，负责时序。两个口都插好了，PowerView 里仍然可能连不上，因为还有第三层——目标芯片是否上电、是否处于复位状态、调试口是否被看门狗或低功耗模式关掉。

3.2 上电与下电的固定顺序

手册给的上电顺序是五步，顺序不能乱：

1. 目标板上电 2. 将 Debug Cable 接到目标板调试口 3. 打开 TRACE32 PowerView，出现欢迎界面 4. TRACE32 主模块上电 5. 用 USB 或网络连接主模块与 PC

下电顺序则是反过来：

1. TRACE32 主模块断电 2. 关闭 TRACE32 软件 3. 断开 Debug Cable 与目标板的连接 4. 目标板下电

为什么上电要先给目标板？因为调试线缆上的引脚直接连到目标芯片的调试接口，如果主模块先上电、目标板还没供电，主模块会通过调试口的钳位二极管向目标板倒灌电流，轻则目标板处于半供电状态导致连接握手失败，重则长期这么干损伤调试口。下电时先断主模块，也是同一个道理——在目标板掉电瞬间让调试器先退出驱动状态，避免 TMS/TCK 线上残留电平把目标芯片拉在复位或半复位状态，下次上电时芯片起不来，你还以为是固件问题。

我见过更隐蔽的一种情况：目标板带独立供电，调试器和目标板接在同一个插排上，一起上下电。这种接法下，时序完全取决于两个电源的上升沿速度，有时能连上有时连不上，属于典型的难以复现的异常现象。只要条件允许，调试器和目标板分开供电、按顺序手动上下电，排查问题时能省下大量时间。

3.3 用设备管理器、lsusb、dmesg 确认枚举

软件装完、硬件按顺序上电之后，先别急着开 PowerView，先确认操作系统层面有没有把调试器认出来。这一步能把「驱动问题」和「连接问题」分开。

Windows 下打开设备管理器，看TRACE32 Devices分类下的设备状态，没有黄色感叹号就说明驱动正常。Linux 下用两条命令：

# 查 USB 设备列表，厂商 ID 为 0x0897 lsusb | grep -i 0897 # 典型输出： # Bus 001 Device 004: ID 0897:0002 Lauterbach ... # 查内核日志，看枚举过程和可能的报错 dmesg | tail -30

lsusb没有任何输出，说明设备根本没枚举上，问题在 USB 线、主模块供电或宿主控制器；有输出但后面 PowerView 还是连不上，问题就往下走一层，去看配置文件和 CPU 选择。dmesg的价值在于能看到枚举失败的具体原因，比如device descriptor read error、unable to enumerate USB device，这类报错基本都指向线材或供电。

手册特别提了一种情况：部分主板或虚拟机（例如 VMware）的 USB 3.0 驱动兼容性不好，会出现识别不了设备。排查方法很土但有效——换一根 USB 2.0 线试。2022 年开始部分型号不再随附 USB 2.0 数据线，需要自备一根放在工具箱里，专门用来排除这类问题。如果确认是驱动本身的问题，可以单独重装，安装程序在(DVD/安装包)\files\bin\<操作系统>\drivers，或者从官网更新页单独下载 USB 驱动包。

4. 启动方式的选择：快捷方式够不够用，命令行能多做什么

环境确认通过之后，就是启动软件这一步。快捷方式和命令行两种方式，新手通常只用前者，等遇到多核调试、需要固定字体和窗口布局、或者要接自动化脚本时，才会发现快捷方式不够用。手册把两种方式都写了，还单独用附录 C 讲命令行启动，说明这不是可选项而是必备技能。

4.1 快捷方式启动做了什么，局限在哪

Windows 下从开始菜单找到 TRACE32 目录，按目标架构点对应的快捷方式：

R.2021.09 及以后的版本已经把 ARM32 和 ARM64 入口合并，不再需要区分；2021 年之前的版本则是两个独立入口，选错了会表现为「CPU 列表里明明有这颗芯片，但就是搜不到」，因为架构入口本身就不对。

快捷方式的好处是快，缺点是它做的事情你完全看不到。它本质上是带着一组默认参数去调用架构对应的可执行文件，并且读取安装根目录下那份公共的config.t32。这带来两个限制：一是无法自定义多核配置、字体、窗口布局、启动时自动执行的脚本；二是根目录的config.t32一旦被改坏，所有通过快捷方式启动的实例都会受影响。多人共用一台调试主机的场景里，这条很容易踩——有人为了改字体把公共配置改了，第二天所有人启动都是同一个奇怪布局，还找不到是谁改的。

4.2 命令行启动与独立配置文件

命令行启动解决的就是上面两个限制。基本形式是调用架构对应的可执行文件，用-c指定配置文件，用-s指定启动后自动执行的脚本：

# Windows：给不同项目各准备一份配置，互不干扰 "C:\T32\bin\windows64\t32marm.exe" -c "C:\T32\cfg\proj_a.t32" -s "C:\T32\cmm\startup_a.cmm" # Linux：路径按实际安装位置替换 /opt/t32/bin/pc_linux64/t32marm -c /opt/t32/cfg/proj_a.t32 -s /opt/t32/cmm/startup_a.cmm

-c后面的配置文件决定这个实例用哪套参数，不指定时才回落到根目录的config.t32。这就是「每个项目一份配置」的实现方式：复制一份公共配置，改掉其中的会话标识和标题，字体、窗口位置、自启动脚本都各自独立。配置文件是纯文本，常见的几项长这样：

OS= ID=PROJ_A_SESSION TITLE=Project A - Cortex-M Target FONT=Fixed,9 PBI=USB

ID用来区分同时运行的多个实例，两个实例用同一个ID会互相抢资源；TITLE是窗口标题，多开的时候靠它认人；PBI是宿主接口类型，USB 连接和网络连接的取值不同。字段名以你安装目录下那份config.t32模板为准，不同版本会有增删，照抄别人的配置容易出现不认识的键。

-s后面的脚本在软件启动完成后自动执行，适合放一些每次都要做的动作，比如选定 CPU 型号、设置 JTAG 时钟、连接目标、复位到初始状态。这样做的好处是省去每天手工点十几下的重复操作，坏处是脚本出错时窗口一闪而过看不清报错，所以脚本调试阶段建议先不挂-s，手工在命令行窗口里逐条敲，确认每条都过了再写进文件。

4.3 CPU 列表里找不到芯片名的四条排查路径

手册附录 B 专门讲这个现象，说明它的出现频率不低。表现是 PowerView 起来了，SYStem.CPU的下拉列表里翻遍也找不到目标型号，或者输入型号名提示无效。按下面四条依次排查，基本能定位：

第一，安装时架构勾选不全。装的是 ARM 包却要调 TriCore，列表里当然没有。回安装程序补勾即可，不用卸载重装。

第二，软件版本早于芯片发布。芯片比软件新，支持列表里就不会有它。处理方式是装官网的增量升级包，把支持库更新到最新，这是增量包最典型的用途。

第三，查的名字不对。列表里很多时候登记的是内核名而不是具体型号名，比如找 S32K144 可能要先选到 Cortex-M4 这一层，再由后续的初始化脚本去匹配具体器件。手册前言里也提到，涉及的平台主要是 ARM、TriCore、PowerPC 这几个大类，具体型号的匹配逻辑随版本变化。

第四，拼写或大小写。这个听起来很傻，但确实是最常见的一种，尤其是从别人文档里手抄型号的时候，多一个空格或少一个后缀都会导致匹配失败。

5. 避坑与排查：五个现场，从枚举失败到 CPU 列表空白

前面几章是按正确流程走的，这一章反过来，把实际调试现场最常撞上的五种情况按「现象 → 原因 → 解决」记下来。这些内容手册里分散在各处，集中看一遍能少走不少弯路。

5.1 连接与枚举类的三个现场

现场一：设备管理器里出现带黄色感叹号的未知设备。

现象是插上调试器后系统提示安装驱动失败，设备管理器里TRACE32 Devices下面显示感叹号，PowerView 启动后报找不到硬件。原因基本是驱动没有正确安装，常见于首次安装时跳过了驱动步骤，或者安装时没给管理员权限。解决办法是到(DVD/安装包)\files\bin\<操作系统>\drivers目录下单独运行驱动安装程序，也可以从官网更新页下载独立的 USB 驱动包重装。装完拔插一次 USB 线让系统重新枚举。

现场二：lsusb能看到设备，但过几秒就消失。

现象是 Linux 下设备枚举成功又掉线，dmesg里能看到反复的枚举和断开日志。原因多数出在供电或 USB 3.0 兼容性上：主模块通过 USB 取电，如果主机口供电能力不足，或者中间接了一个不带外接电源的 HUB，就会出现这种反复重连。解决办法是直连主机后置 USB 口、换一根 USB 2.0 线、去掉中间 HUB。虚拟机环境下还要检查 USB 控制器版本设置，把兼容性调成 2.0 往往直接就正常了。

现场三：PowerView 提示连接失败，但设备枚举正常。

现象是硬件认出来了，软件一 Connect 就报错，目标板看着也在运行。原因是上下电顺序不对，目标芯片处于复位、低功耗或者调试口被关闭的状态。解决办法是按第 3 章的五步顺序完整重来一遍：目标板先断电，断开调试线缆，等几秒让电容放完电，再按上电顺序重新走。带独立供电的目标板尤其要注意这一点，共用插排一起上下电的接法要尽量避免。

5.2 启动与配置类的两个现场

现场四：改了个字体，结果所有实例的界面都变了。

现象是某人调了一下窗口布局或字体，第二天所有人启动 TRACE32 都变成那个样子，甚至有人反映启动时报配置错误。原因是大家都在用安装根目录下那份公共的config.t32，任何修改全局生效。解决办法是给每个项目、每个使用者复制一份独立配置，用-c参数指定，公共config.t32只保留一份未修改的原始副本作为模板，改坏了随时能覆盖回来。这条经验对多人共用调试主机的团队尤其重要。

现场五：用增量包覆盖后，某些原本能用的功能报错。

现象是升级完支持库，新芯片能识别了，但原来的脚本执行时报某个命令不存在或者行为变了。原因是增量包只提供最新版本的文件，覆盖是单向的、没有回滚，旧版本里的一些脚本接口在新版本中可能已经调整。解决办法是覆盖前把整个 T32 目录压缩备份，升级后先用一个最小脚本跑一遍关键命令，确认没问题再让全组升级。已经出问题的话，解压备份恢复，然后单独在一台机器上验证新版本，确认无误后再推广。

6. 把调试环境做成模板：网络连 LA-3505 与 cmm 脚本固化

到这一步，单机单板的手工调试已经能跑通了。真正省时间的是把这些步骤固化成可复制的模板：调试器走网络、配置按项目分文件、启动脚本自动完成初始化和连接。手册附录 A 讲的是 LA-3505 的网络连接，附录 C 讲的是命令行启动，两件事合起来正好是一套可复现环境的基础。

6.1 LA-3505 走网络连接的两段配置

LA-3505 支持 USB 和以太网两种宿主连接，走网络前必须先给主模块指定 IP 地址。这个地址不是插上网线自动获取的，需要先在 USB 连接状态下配置好，手册附录 A 给了完整步骤。配置完成后，把启动配置里的宿主接口从 USB 改成网络，并指定主模块地址。常见写法是在config.t32里把接口项换掉：

OS= ID=PROJ_A_NET TITLE=Project A - LA-3505 over Ethernet PBI=NET NODE=192.168.10.20

PBI决定宿主接口类型，NODE指向主模块地址，具体字段名和取值以手册附录 A 以及你安装目录下的配置模板为准，不同版本之间会有差异。改完之后不要直接拿去连目标板，先用一个空配置启动、只验证网络这一层能不能握手成功，成功后再叠加 CPU 初始化和连接脚本。分层验证的好处是出问题时能立刻判断是新加的配置错了，还是底层网络本来就不通。

网络连接带来的实际收益是调试器可以放在目标板旁边，人在另一台机器上操作，多个人也能轮流连同一台调试器，不用挤在工位边上插拔 USB 线。代价是多了一层网络依赖，交换机、网段、防火墙任何一处变了都连不上，所以 IP 地址建议做成固定分配并记录在项目文档里。

6.2 用 cmm 脚本固化初始化流程

每次启动都要手工选 CPU、设时钟、连接、复位，这套动作重复几十遍之后就该写成脚本了。TRACE32 的 Practice 脚本（.cmm）就是干这个的，配合-s参数在启动时自动执行：

; startup_a.cmm - 启动后自动完成目标连接 SYStem.CPU S32K144 ; 选定目标 CPU 型号 SYStem.JtagClock 1MHz ; JTAG 时钟先降速，连接稳定后再提 SYStem.Up ; 连接目标并停在初始状态 Break ; 停在第一条指令前，等人工介入

脚本里前两条是关键。SYStem.CPU指定的型号必须和安装时勾选的架构对得上，对不上会直接报错退出；SYStem.JtagClock一开始不要给太高，目标板走线长、电源不稳的时候高速时钟很容易握手失败，先用 1MHz 连上，确认稳定后再改到目标值。SYStem.Up完成实际连接，这一步失败的话脚本会中断，窗口里能看到具体错误码。

我一般的做法是把脚本拆成两段：一段只做连接，一段做后续的加载和断点设置。调试环境有问题时只跑第一段，确认物理链路和 CPU 选择没问题，再去排查应用层的东西。这种拆分在换了新板子之后特别有用，因为新板子出问题十有八九在连接层，不在应用层。

6.3 一次性的验证清单

环境搭好之后，在交给别人用之前，按下面这张表过一遍。每一项都是独立的，任何一项不过都说明这套环境还不能拿去给别人用：

这张表的用法是逐项打勾，不要跳着验。我踩过最没必要的坑，就是前面几项都过了、直接跳到连接脚本，结果卡了两小时才发现是安装时架构勾错了——如果按顺序先验第二项，五分钟就能定位。

从那以后我每装完一台 TRACE32，都会先把设备枚举结果截图存档，再跑一遍最小连接脚本，最后才把环境交给别人。这多花的十分钟，比事后远程指导别人排查省下的时间多得多。希望帮到你。

本文还有配套的精品资源，点击获取