劳特巴赫Trace32快速入门：安装、硬件链路与PowerView启动顺序

简介：《劳特巴赫TRACE32快速入门》面向嵌入式调试初学者及需要上手LAUTERBACH调试器的工程师，围绕TRACE32的安装、硬件环境搭建与软件启动建立基础认知，帮助读者解决初次接触时环境配置零散、连接确认困难等问题。压缩包共1个PDF文件，约6.17MB，内容以图文步骤和附录专题组织，覆盖安装包获取、调试器连接方式、上下电顺序、环境确认及快捷方式启动等入门环节；附录进一步延伸至PowerView通过网络连接LA-3505、CPU列表中找不到目标芯片的排查，以及命令行启动等实用场景。已有6473人学习，说明其在嵌入式调试入门群体中具有一定参考价值。读者可借此梳理从软件落地到目标板联调的完整路径，并了解断点、内存查看、寄存器操作与Trace跟踪等功能的后续学习方向，适合作为查阅式入门手册配合安装目录文档使用。

1. 从一块连不上的板子说起：这套环境到底该按什么顺序搭

新机器、新装的系统，插上调试头，设备管理器里躺着一个黄色感叹号——这是不少人第一次接触劳特巴赫 Trace32 调试器时的真实场面。软件装了三遍、驱动重装了两次，最后发现是 USB3.0 口不认那根线。这类问题在手册里只占一行字，在现场能耗掉半天。

这份快速入门手册的价值就在这里：它不铺开讲断点、Trace、覆盖率这些高阶功能，而是把“从零到能连上目标核”这一段拆成可执行的步骤——安装包从哪来、平台选项怎么勾、主模块和调试头怎么接、上下电按什么顺序、PowerView 用哪种方式启动、网口连不上时看哪里。面向的是刚接手 TriCore、ARM、PowerPC 平台调试的工程师，也适合已经会用但环境总是搭不干净、每次换机器都要重踩一遍坑的人。

2. 装包与安装：版本、平台勾选和两个系统的差异

安装这一步翻车的概率其实不低，但翻车点很集中：拿错了包的类型、平台选项少勾了一个、路径里带了空格。把这三点按顺序排掉，后面基本不会再有软件层面的问题。

2.1 四种来源，先分清“完整包”和“增量包”

手册列了四条获取路径，它们的适用场景完全不同，混用会出问题。

第四条是最容易搞错的。增量包下载下来没有 setup.bat，也不需要安装，解压后把里面的文件全选、复制到原有 TRACE32 安装目录覆盖旧文件即可。覆盖之前我一般会把整个安装目录打一个压缩包备份——TRACE32 的配置和自定义脚本都放在安装目录下，覆盖是不可逆的，没有后悔药。另外增量包只提供最新版本，如果项目要求固定在某个旧版本（比如验证过的 R.2020.09），就只能用完整包重装，别想着用增量包降级。

官网注册那一步会被序列号卡住，序列号在调试头本体或者随附的标签上。注册完之后有新版本发布会收到邮件提醒，这个对长期跟进新芯片支持挺有用，但如果是给产线或实验室装机器，建议还是把安装包本地归档一份，别指望每次都能顺利登官网。

2.2 Windows 下按典型安装走，平台勾选别偷懒

以 Windows 10 64 位装 R.2022.02 为例，流程本身不复杂：

1. 解压安装包，运行根目录下的setup.bat启动安装程序（不是 setup.exe，注意扩展名）。
2. 前面几屏保持默认，一路 Next。
3. 安装类型界面选 Typical Installation，典型安装。
4. 平台选择界面，按你要调试的芯片勾选对应的架构支持。
5. 驱动安装环节全部允许。
6. 最后一屏询问是否注册，可以跳过，之后从软件里补。

第四步是重点，勾错了软件能装成功，但打开后 CPU 列表里就是找不到目标芯片，很多人会误判成“版本太老不支持”。对照关系大致是这样：

多核芯片要特别注意：主核和 HSM 核分属不同架构入口时，两个都得勾上，只勾主核会导致 HSM 侧无法 attach。另外 2021 年之前的版本，ARM32 和 ARM64 是两个分开的安装入口，Cortex-M 和 Cortex-A53 装在同一台机器上需要分别装；R.2021.09 之后合并成一个入口，这一点在给老项目复现环境时要留意。

安装路径上，我一般不会装在C:\Program Files\下面。原因有两个：TRACE32 运行时会往安装目录写配置、日志和临时文件，Program Files 的 UAC 保护会拦下来；路径里如果带空格或中文，命令行启动和 cmm 脚本里的相对路径容易解析出问题。统一放D:\T32\这种短路径，后面省很多事。

2.3 Linux 下先补 Qt 依赖，再跑 setup_linux.sh

Linux 侧的坑基本都在依赖上。以 Ubuntu 64 位装 R.2020.09 为例，装之前把 Qt5 的运行库补齐：

# TRACE32 的 PowerView 界面依赖 Qt5，缺库时表现为启动即退出 sudo apt-get install libqt5gui5 sudo apt-get install libqt5printsupport5 # 部分发行版/精简系统还会缺下面两个，报错时按提示补 sudo apt-get install libqt5widgets5 sudo apt-get install libqt5core5a

这段的作用是把图形界面依赖装齐。libqt5gui5是窗口渲染的基础库，libqt5printsupport5对应打印和导出功能模块，缺前者的典型现象是在终端里执行启动命令后立刻返回，或者报error while loading shared libraries: libQt5Gui.so.5: cannot open shared object file。不同发行版的包名有差异，CentOS 系一般叫qt5-qtbase、qt5-qtbase-gui，装之前先用ldd看一下可执行文件缺哪些 so 更直接。

依赖齐了之后进安装包目录执行安装脚本：

# 进入光盘或安装包解压后的目录 cd /media/cdrom # 安装驱动阶段需要 root 权限，直接 sudo 跑整个脚本最省事 sudo ./setup_linux.sh

setup_linux.sh会走和 Windows 类似的向导，按提示选安装路径和平台。这里需要 root 的原因不是复制文件，而是安装设备驱动和写 udev 规则——普通用户默认没有权限直接打开 USB 设备节点，如果驱动装上了但普通用户启动软件报权限不足，多半是 udev 规则没写进去或者没重新加载。我的习惯是装完之后拔插一次调试头，再执行sudo udevadm control --reload-rules让规则生效，然后才用普通用户启动，避免一直用 root 跑调试器把配置文件的属主搞乱。

3. 硬件链路：主模块、调试头与上下电的固定顺序

软件装完只是上半场。TRACE32 是软硬件成套的系统，链路上任何一个环节接错，表现都是“软件里看不到调试器”，和软件没装好长得一模一样，很容易误判。

3.1 先认主模块型号，再决定用 USB 还是网口

整套链路的物理顺序是：PC → 主模块（PowerDebug）→ 调试头 / Debug Cable → 目标板调试口，另外主模块单独有一路调试器电源。上位机和主模块之间的连接方式由主模块型号决定，这一步选错，后面怎么调都没用。

LA-3505 用 USB 连接时，接线方式和 LA-3500 一致：USB 线接 PC，调试器电源单独供电，Debug Cable 接到目标板调试口。走网络时多一步 IP 配置，好处是调试器可以放在目标板旁边，人在另一台机器上连，长线调试和多人轮流用同一套硬件时很方便。

μTRACE 这类小盒子别当成主模块用，它没有网口，也没有外接调试器电源的独立接口，供电和通信都走 USB。带载能力弱一些，接大电流目标板时要留意 USB 口的供电余量。

3.2 上下电顺序：反了不是玄学，是 IO 打架

手册给的顺序是有讲究的，我第一次看觉得啰嗦，后来被烧过一次调试头的 IO 才老实。

上电顺序：

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

下电顺序完全反过来：

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

这套顺序的核心是“主模块最后上电、最先断电”。主模块上电的瞬间，调试口引脚的电平状态是不确定的，如果此时它已经通过 Debug Cable 和目标板的 IO 连在一起，而目标板处于上电工作状态，就可能出现两端同时驱动同一组引脚的情况，轻则识别异常，重则通过 IO 灌电流。反过来，先给目标板上电再连调试线，是为了让调试头的地先和目标板共地，避免热插拔瞬间的电位差。

现场做不到这么严格的时候（比如目标板在机柜里，调试线常年插着），至少保证软件层面的顺序：先关软件再断硬件，别在 PowerView 还开着的时候直接拔调试头。这样虽然省不掉硬件上的热插拔，但能避免软件侧留下没释放的会话，下次连的时候报设备占用。

3.3 环境确认：三个地方看设备到底认没认到

在第一次使用的新 PC 上，软件装好、硬件按顺序上电之后，先别急着开软件，确认系统层面认到了设备。这一步跳过去，后面所有报错都缺少判断依据。

Windows 下打开设备管理器，找TRACE32 Devices分类，正常情况下能看到具体设备条目，没有黄色感叹号。如果出现在“其他设备”里并且带感叹号，就是驱动没装好，直接重装驱动，路径在安装包或安装目录的files\bin\<操作系统>\drivers下面，官网更新页也提供单独的驱动包。

Linux 下用两条命令交叉验证：

# 查看内核日志里最近的 USB 枚举记录 dmesg | tail -n 30 # 按厂商 ID 过滤，确认设备在总线上 lsusb | grep -i 0897

第一条看的是内核有没有完成枚举，插入设备后应该能看到新设备接入的记录；如果什么都没有，说明是物理层或 USB 控制器的问题，跟 TRACE32 无关。第二条按厂商 ID 过滤，劳特巴赫的 USB Vendor ID 是0x0897，手册里常写作0x897，补零后就是四位。lsusb能列出来但软件打不开，基本就是权限或驱动问题；lsusb也列不出来，回去查线和口。

这里有个高频坑：USB3.0 口。部分主板和虚拟机（比如 VMware）的 USB3.0 控制器在透传时兼容性不好，表现就是设备时认时不认，或者干脆认不到。排查手段很土但有效——换一根 USB2.0 线插到 USB2.0 口上试。如果换线就好了，问题就定位在 USB3.0 链路上，不用再折腾驱动。需要注意 2022 年开始部分型号不再随附 USB2.0 数据线，得自己备一根，别等到现场才发现没得换。

4. 启动 PowerView：快捷方式、配置文件和命令行

同一个软件有三种启动姿势，区别不在能不能用，而在配置的隔离程度。选错姿势的代价通常不是当次调试失败，而是“我这边好好的，同事那边全乱了”。

4.1 快捷方式启动：快，但配置是共享的

Windows 下最省事的方式是开始菜单里的 TRACE32 目录，按架构点对应的快捷方式：

• 调试 TriCore 平台，点TRACE32 ICD Tricore USB
• 调试 MPC5xxx 平台，点TRACE32 ICD PPC USB
• 调试 Cortex-R8 / Cortex-M / Cortex-A9，点TRACE32 ICD ARM32 USB
• 调试 Cortex-A53 一类，点TRACE32 ICD ARM64 USB（R.2021.09 之后 ARM32/ARM64 入口已合并）

优点是快，双击就出欢迎界面，不用记任何参数。缺点手册里写得很直白：只能在 Windows 下用；没法带自定义配置，多核设置、字体、自启动脚本都得进去以后手动改；最要命的是快捷方式读的是安装根目录下的配置文件，这个文件一旦被改坏，影响的是这台机器上所有 TRACE32 实例。

实验室共用机器的场景最容易中招。一个人为了调多核把根目录的配置改了，第二天所有人启动都是他那套设置，有人调不通还以为是自己板子的问题。我在共用环境里从不直接用开始菜单的快捷方式，都是自己复制一份配置另起快捷方式，具体做法在下一节。

4.2 一份 config.t32 该改哪几行

TRACE32 的启动配置就是一个纯文本文件，安装目录下叫config.t32，每行一个关键字，分节靠空行。日常改动的其实就那么几行：

; 每行一个配置项，空行做分节 OS= ID=MyArmDebug PBI=USB USB PRINTER=WINDOWS SCREEN= FONT=SYSTEM ; 走网络连 LA-3505 时，把上面两行换成下面这组 ; PBI=NET ; NET=192.168.1.50

逐行说清楚：ID是这个实例的标识，多个实例同时开的时候用来区分窗口，改成本项目的名字最直观；PBI指定上位机和主模块之间的物理接口，USB 连接写USB，网络连接写NET；紧接着单独一行的USB是 PBI 的补充声明，这两行是配套的，删了会起不来；PRINTER、SCREEN、FONT属于界面相关的可选项，FONT=SYSTEM用系统字体，避免高分屏下字小到看不清。

改法上，我的习惯是复制安装目录里的原始config.t32，重命名成config_<项目名>.t32放到项目目录里，原文件一个字不动。这样一个项目一套配置，换项目只要换启动参数，不会互相污染。配置文件里带绝对路径的项尽量少写，项目目录一挪就全废。

4.3 命令行启动：给每个项目一套独立配置

自定义配置要生效，就得从命令行启动，用参数把配置文件指过去：

# Windows：在安装目录下执行，-c 指定配置文件路径 t32marm.exe -c .\config_tc397.t32 # Linux：Linux 下可执行文件没有 .exe 后缀 ./t32marm -c ./config_tc397.t32 # 顺带在启动时执行一段初始化脚本，-s 指定脚本 t32marm.exe -c .\config_tc397.t32 -s .\startup.cmm

可执行文件名按架构区分：t32marm对应 ARM 系列，t32mtc对应 TriCore，t32mppc对应 PowerPC/Power 架构。-c后面跟配置文件的相对或绝对路径，不写就用当前目录下的config.t32；-s后面跟 cmm 脚本路径，软件启动完成会自动执行一遍，适合放 CPU 型号设置、JTAG 时钟、自动加载 elf 这类固定动作。

这两个参数配合起来，一个具体项目就能固化成一行启动命令：配置隔离了，初始化脚本也隔离了，新同事拿到命令和两个文件就能复现出一样的调试环境，不用口头传授“你先点这个再点那个”。Windows 下可以把这行命令写进一个.bat，再给 bat 建快捷方式换个图标，用起来和开始菜单里的快捷方式没差别，配置却是自己的。

4.4 网络连接 LA-3505：先配 IP，再改 PBI

附录 A 那条路径，本质是把 4.2 里的PBI=USB换成PBI=NET并补上 IP。前提是主模块的 IP 已经配好，且和 PC 在同一网段。

常见做法是先用 USB 连一次，进软件把主模块的网络参数设好（IP、掩码、网关），保存后再拔掉 USB 改用网线。IP 分配上建议给调试器一个固定地址，别走 DHCP——调试器重启后地址变了，配置文件里的NET=就指向空，表现是启动后一直提示连接不上，很容易被误判成网线坏了。

改完配置先别开软件，用系统的连通性测试确认链路：

# 替换成主模块实际配置的 IP ping 192.168.1.50 # Windows 下看 arp 表，确认 MAC 层也通了 arp -a | findstr 192.168.1.50

ping通说明网络层没问题，可以往下走；不通就先查网线、交换机端口和 PC 側的防火墙，PC 和调试器不在同一网段时ping是必然不通的，别急着改 TRACE32 配置。防火墙这块经常被忽略：Windows 的公用网络配置文件默认会拦掉部分入站流量，把网卡改成专用网络再试一次往往就好了。

网络连接的实际收益是距离和解耦。调试器可以常年挂在目标板旁边，PC 在工位上连过去，不用每次搬着机器跑；多人协作时也可以轮流连同一台调试器，只是要注意同一时间只能有一个会话占用，前一个人没关软件，后一个人连上去会提示设备忙。

5. 常见问题排查：五条现场记录

下面这几条都是“软件装好了、线也接了、就是不工作”的典型，按现象、原因、解决三段记，遇到时对着症状找就行。

5.1 设备管理器里出现未知设备，驱动装了两遍还是感叹号

现象：插上调试头，设备管理器在“其他设备”里多出一个带黄色感叹号的条目，名字不是 TRACE32 Devices，重装安装包自带的驱动也没变化。

原因：驱动装到了错误的设备实例上。Windows 对同一个 VID/PID 的未知设备会缓存上一次失败的安装记录，直接重装驱动有时不会重新匹配，而是沿用旧的失败状态。

解决：在设备管理器里右键卸载该设备，勾选“删除此设备的驱动程序软件”，拔掉调试头，重新插上让系统重新枚举，再手动指向安装目录files\bin\<操作系统>\drivers下的驱动。还不行就换一个 USB 口，尤其是从 USB3.0 换到 USB2.0，主板不同控制器的枚举行为不一样。

5.2 上午能连，下午同一个口连不上，换根线就好了

现象：设备时认时不认，插拔几次偶尔能识别，跑一会儿又掉。换一根 USB2.0 线插 USB2.0 口之后稳定。

原因：USB3.0 链路的兼容性问题，主机控制器、线材质量、虚拟机 USB 透传三者中任一环不稳都会这样。手册里专门提了这一条，尤其是 VMware 这类虚拟化环境。

解决：优先用 USB2.0 线 + USB2.0 口做交叉验证，能稳定就固定用这套组合，不要为了“口多”去插 USB3.0。2022 年起部分型号不再附赠 USB2.0 线，自己备一根放工具箱里，这是我见过性价比最高的一件调试备件。

5.3 PowerView 能起来，但连目标核时报错

现象：软件界面正常，欢迎界面也出来了，点连接或者执行 attach 时提示找不到目标或者 JTAG 通信失败。

原因：按概率排序，依次是目标板没上电、Debug Cable 没插到位、JTAG 时钟设得过高、目标核处于复位或低功耗状态。软件本身没问题的概率其实最大。

解决：先用万用表确认目标板供电，再看调试口的第几脚是 VREF，很多板子要求调试器检测到参考电压才肯输出信号。时钟先降到 1MHz 以下试，能连上再往上加，加到不稳就退回上一档。目标核被看门狗反复复位的情况也常见，先关看门狗或者按住复位再连。

5.4 CPU 列表里找不到想调试的芯片

现象：安装一切正常，平台也勾了，但新建会话时 CPU 下拉列表里就是没有目标型号。

原因：三种可能——装的版本太老，新芯片还没进支持列表；平台选项勾选不全（多核芯片只勾了主核）；装的是某个精简配置，对应的 CPU 支持文件没落盘。

解决：先查安装目录pdf文件夹里对应处理器系列的文档，确认这个型号从哪个版本开始支持；版本不够就用增量包升到最新，或者用完整包重装。平台勾选回到 2.2 的对照表重新对一遍。手册的附录 B 专门讲了这个场景，思路就是先排除版本、再排除勾选，最后才怀疑硬件。

5.5 改了根目录配置，第二天所有人都连不上

现象：自己调完多核设置，第二天同事启动软件发现字体、窗口布局、核配置全变了，有人直接连不上目标。

原因：用开始菜单快捷方式启动，读的是安装根目录下那份共享的config.t32，谁改谁生效，没有隔离。

解决：把原始配置文件恢复回去，然后按 4.2 的做法给每个项目复制一份独立配置，用命令行-c启动。共用机器上这一点必须提前约定，否则每次都要花时间排查“是不是板子坏了”。

6. 把环境检查固化下来：一段脚本加一张表

前面几章的动作，熟练之后其实十几分钟就能走完，但换机器、换项目、隔几个月再来一次的时候，记忆是靠不住的。我的做法是把能固化的部分全部固化成文件，只留下必须人工判断的环节。

先是一段启动脚本，用-s参数挂上去，把每次都要手点的动作省掉：

; startup.cmm - 放在项目目录，配合 -c 指定的配置文件使用 ; 设定目标 CPU 型号，型号名以 pdf 目录下对应手册为准 SYStem.CPU CortexM7 ; JTAG 时钟先给保守值，连稳了再往上调 SYStem.JtagClock 8MHz ; 建立调试会话 SYStem.Up ; 加载 elf，/NoClear 表示不清除已加载的段 Data.LOAD.Elf .\app.elf /NoClear ; 在 main 上打个断点，然后全速跑 Break.Set main Go

这几行的顺序不能乱：SYStem.CPU必须在SYStem.Up之前，CPU 型号决定了核的寄存器布局和内存映射，先连后设会读到错的地址空间；SYStem.JtagClock同理，时钟是在建立会话时协商的，连上之后再改要重新 Up 一次。Data.LOAD.Elf后面的/NoClear是个实用参数，调试中途重新加载时不会把已经写进去的数据段清掉，避免反复烧写。Break.Set main依赖符号表，elf 里没有调试信息的话这条会失败，但不会中断脚本执行，所以脚本跑完发现没停在 main，先检查编译选项里有没有-g。

再是一张开机检查表，贴在调试台旁边，五分钟能过一遍：

这张表的用法是倒着排查：从下往上看，CPU 列表里没有型号，说明是安装阶段的问题，回去查 2.2 的平台勾选和版本；列表里有但连不上，往上走查配置和网络；网络通了还连不上，再往上查 USB 和上电顺序；系统层面就认不到设备，直接查线和口。把“哪一层出的问题”先定下来，比盲目重装软件快得多。

最后说个习惯。早些年我不备份安装目录就直接覆盖增量包，结果一套调了半个月的多核配置连同自定义脚本一起没了，重配花的时间比调试本身还长。从那以后我每次升级或改动安装目录之前，都强制先打一个压缩包备份，配置一律走项目私有的config_<项目名>.t32，根目录那份原封不动。这套规矩看着笨，但让我在后面几年里再没因为环境问题耽误过进度。希望帮到你。

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