AURIX TC375 开发环境搭建：ADS 安装、工程创建与调试实战

做车规控制器开发，绕不开 AURIX。TC375 是英飞凌 AURIX TC3xx 家族里的中坚型号，很多做 BMS、网关、底盘域控制器的团队都在用这颗料。AURIX Development Studio（也就是大家常说的 ADS）是英飞凌官方推出的免费 IDE，和 Keil、IAR 那种商业许可证模式完全不同，装上就能用。这篇文章把从零到能点灯、能调试的完整过程写出来，包括 ADS 2023 的安装、第一个 TC375 工程创建、LSL 链接脚本和启动流程，最后再分享一些调试器使用和问题排查的实战经验。适合刚拿到 TC375 开发板、还没有跑通 ADS 的工程师，也适合想从 TC2xx 转 TC3xx 的朋友。

1. 为什么是 TC375：先搞清楚这套环境在搞什么

1.1 TC375 到底是一颗什么芯片

AURIX TC3xx 系列是英飞凌在 TC2xx 基础上的换代架构，TC375 属于这个家族里的“次旗舰”位置。虽然它不像 TC39x 那样拥有巨大的 Flash 和 RAM，但三核 TriCore 架构、主频可达 300MHz，再加上丰富的外设集合，已经能覆盖绝大多数汽车域控制器的需求。很多团队选 TC375 做预研和量产，一方面是算力够用，另一方面是它管脚、外设和 TC3xx 系列其他型号高度兼容，后续往 TC367、TC397 迁移，软件改动量相对可控。

从芯片内部看，TC375 最有特色的地方不是“核多”，而是三个核里每个都带着 DSP 和浮点能力，还有硬件锁步核可以对关键任务做冗余保护。加上片内集成的存储保护、时钟监控、电压监控这些安全机制，它能够支撑 ASIL-D 级别的功能安全设计。不过这些安全机制对刚上手的人也是双刃剑，比如 Endinit 保护、看门狗这类东西，配置不到位会让你程序跑得莫名其妙。后面谈调试技巧时我会专门展开。

对于初学者来说，你手上最好有一块官方的开发板，比如 KIT_A2G_TC375_LITE 这种 LiteKit。板载 DAP 调试器、LED、按键和扩展接口基本齐全，不需要额外买调试器，插上一根 USB 线就能开始测例程。千万别一上来就用自己画的板子去学环境，万一供电或晶振出了问题，你会分不清是硬件问题还是软件配置问题。

1.2 ADS 和 Keil/IAR 的区别在哪里

很多从 ST、NXP 转过来的工程师，第一反应是“能不能用 Keil 或者 IAR 开发 AURIX”。答案是能，但官方和社区的主要生态都集中在 ADS 上。ADS 是英飞凌基于 Eclipse 做的集成开发环境，默认集成了 TASKING 编译器，下载安装后不需要额外找 License 文件，这一点比 Keil 的评估版和 IAR 的代码限制版友好得多。

ADS 和 Keil 最大的不同是工程模型。Keil 的工程通常就是 Device、启动文件、外设库，你只要配置好宏和头文件路径就行。ADS 里的工程更偏向 Linux 工具链那套思路，你不仅要管编译文件，还要管链接脚本 LSL、启动代码、多核配置。第一次打开一个 AURIX 工程的人，会被里面一大堆文件夹和 .lsl 文件吓到，但你只要理解它的分层逻辑，后面用起来反而比 Keil 更透明。

还有一点容易混淆，很多做射频或微波的人一听到 ADS 会以为是安捷伦/是德科技的 Advanced Design System 仿真软件。这里说的是 AURIX Development Studio，和电磁仿真完全无关。你在搜索资料时加一个“AURIX”关键词，能少走很多弯路。

1.3 搭建环境前需要准备的软硬件清单

不要急着装软件，先把家当备齐。如果你手头已经有 TC375 开发板，只需要确认板载调试器是什么类型。官方 LiteKit 通常使用 DAP 接口，通过 USB 枚举出一个调试器设备，电脑会识别为 Infineon DAS 相关的调试适配器。如果用的是第三方核心板，可能要配一套 MiniWiggler 或仿真器，驱动方式稍有区别。

软件方面，主要就是三样：AURIX Development Studio 本体、DAS 驱动（部分 ADS 版本安装时自带），以及一个顺手的串口工具。ADS 的体积不算小，安装包一般超过 1GB，建议用稳定的网络下载，并确保电脑有足够的磁盘空间。操作系统建议用 Windows 10/11 的 64 位版本，Ubuntu 也能跑，但 Windows 下调试器驱动最省心。

这里有一个安装前我反复强调的坑：整个工作路径不要出现中文、空格和特殊字符。ADS 的构建系统对路径比较敏感，假如你放在D:\开发\TC375 项目这种目录下，编译时很可能报一些莫名其妙的“cannot open file”错误。宁可老老实实建一个D:\AURIX_TC375\workspace，后面会省掉大量时间。

2. 从零搭建 ADS：下载、安装、创建工作区的完整过程

2.1 官网下载 ADS 并完成安装

下载 ADS 需要到英飞凌官网搜索 AURIX Development Studio，进入页面后一般要求注册或登录 My Infineon 账号。如果你是从第三方网盘拿到的安装包，建议先核对一下版本，老版本 ADS 虽然能建工程，但对 TC3xx 新芯片的调试支持可能不完整。

安装过程本身不复杂，双击安装包，选择安装目录，一路 Next 即可。但我建议把默认的 C 盘路径改到 D 盘，不是因为 C 盘装不下，而是 ADS 会随版本更新反复覆盖工作区，放在独立盘符上后续整理资料会舒服很多。安装结束时如果提示安装 DAS 驱动，尽量勾选，没有这个驱动，板载调试器和 MiniWiggler 都识别不出来。

装完之后先不要急着建工程。我的习惯是先打开 ADS 安装目录下的plugins和examples文件夹，看看有没有官方自带的例程压缩包。很多 ADS 版本会随包附带一批 AURIX 例程，其中就包含 TC375 的GPIO_Blinky_LED、MCMCAN、UART_ASC等经典模板。这些例程是验证环境是否正常的最快捷径，比自己从空工程手动配 LL 库靠谱得多。

2.2 用向导创建第一个 TC375 点灯工程

打开 ADS 后，你看到的其实是一个定制过的 Eclipse，菜单结构和 STM32CubeIDE 很像。新建工程的入口一般在File -> New -> AURIX Development Studio Project。与 Keil 直接选芯片型号不同，ADS 向导需要填工程名、选择芯片、选择编译器，然后选择模板。以 TC375 为例，芯片系列选 AURIX TC37x 或者直接搜索 TC375，编译器选 TASKING，模板优先选带“Blinky”或“Hello World”的工程。

工程创建完成后，项目树里会看到0_Src、1_Services、3_Infra这类分层目录，初次看会有点懵。这里简单提一下它们的逻辑：0_Src是应用代码，1_Services是服务和系统相关代码，3_Infra主要放 iLLD 驱动库。不要乱动 iLLD 库的路径，否则编译时头文件一堆问题。

下一步就是修改点灯代码。如果你选的是GPIO_Blinky_LED模板，代码里已经有initLED和blinkLED这样的函数。想换成自己板子的引脚时，要用 iLLD 的端口接口：

IfxPort_setPinMode(&MODULE_P00, 0, IfxPort_Mode_outputPushPullGeneral); IfxPort_setPinState(&MODULE_P00, 0, IfxPort_State_low);

注意这里的MODULE_P00是端口模块寄存器地址，引脚号由第二个参数指定。不同型号的板子引脚映射不一样，记得参考开发板原理图，不要照抄别人的 pin 编号。

2.3 编译、烧录之前必须检查的配置

工程能编译不代表能点灯，烧录前有几个关键配置要核对。首先是工程右键进入Properties，查看 C/C++ 构建设置里有没有正确包含 iLLD 的头文件路径。正常情况下模板已经配好，但如果你的工程是从网上下载的二手工程，编译时经常会出现找不到IfxPort.h一类的错误，这时候不要急着手动加一堆路径，而是先看一下工程是不是完整导入。

其次是调试器配置。点击工具栏上的调试按钮（小虫子图标），第一次调试会弹出调试配置窗口。这里需要在Debugger或者Target页面选择 Target Device 为 TC375，调试器选 DAS 或者 DAP。如果下拉列表里没有对应选项，说明 DAS 驱动没装好，或者板卡没有连接成功。建议先到设备管理器里确认 USB 设备是否枚举为“Infineon DAP”相关设备。

最后是 Flash Download 设置。ADS 的调试模式会把程序下载到 Flash 还是 RAM，取决于你选的启动配置。调试阶段我喜欢设置成“Download to Flash”并保留断点，否则下次板上电程序不会自动运行。有人在做纯 RAM 调试时发现断点可以停但功能异常，那就是 Flash 和 RAM 映射不一致导致的。

3. 工程背后的关键细节：LSL 链接脚本、启动流程与 iLLD 驱动

3.1 LSL 链接脚本到底管了什么

很多从 Keil 转过来的人第一次看到.lsl文件都会头疼。LSL 全称 Linker Script Language，是 TASKING 编译器专用的链接脚本，作用类似于 GCC 的.ld文件。它定义了一段代码放在 Flash 哪个地址、变量放在 RAM 哪个区域、栈和堆在哪儿、CSA（上下文保存区）怎么分配。

TC375 内部有多个 CPU，每个核都有自己的 PC、PSW 和寄存器组，LSL 里会对每个核分别指定startup入口和栈地址。默认模板给出的 LSL 通常已经覆盖了 Cpu0、Cpu1、Cpu2 的启动区，不建议新手大改。真正需要改的场景往往是你自己设计了一个内存分区，比如给 Autosar 的 Os 配置预留一块固定 RAM，或者把一段代码搬运到本地 LMU，这时候再去看 LSL 的memory和section_layout语法。

如果你遇到链接器报cannot open link script file，八成是工程路径或文件名冲突。另外提醒一句，LSL 里的地址必须和芯片头文件里的寄存器映射一致。TC3xx 系列地址空间比较特殊，程序 Flash、数据 Flash、CPU 本地 RAM 是分开的，别拿 STM32 那套“Flash 从 0x08000000 开始”去套，否则程序跑飞了还不知道。

3.2 TriCore 启动过程为什么会卡死在 main 之前

做过 STM32 的都知道，上电后会从向量表取出复位向量，然后进入 Reset_Handler，再初始化系统时钟和调用 main。TriCore 的启动流程不太一样。TC375 内部有一个 BootROM，芯片上电后 BootROM 会先执行，然后根据硬件引脚配置决定是加载用户程序还是进入调试模式。

ADS 模板工程里你并不会看到一个startup_TC375.s文件，TASKING 编译器把启动代码打包到了库里。如果你想把系统时钟、看门狗的初始化和 C 运行时环境初始化看明白，可以在0_Src_0_Startup或者1_Services里找到类似Ifx_Ssw_Tc0_Init的函数。简单说，用户 main 执行之前，CPU 已经完成了栈指针、CSA、全局变量清零、时钟切换等一堆动作。

很多新手遇到的现象是：程序下载成功了，但断点永远停在 main 第一行之前的某处，或者复位后程序根本不进 main。最常见的两个原因：看门狗没关，或者时钟配置把系统拉到非法频率。调试器里看到的 PC 停在 0xA0000020 这类 BootROM 区域，基本就是没有走出复位流程。建议在 main 入口第一行就设一个硬件断点，如果每次都能停住，说明启动链路是通的，再往后查外设初始化。

3.3 被很多人忽视的 iLLD 初始化顺序

iLLD 是英飞凌官方提供的一层外设驱动库，全称 Infineon Low Level Driver，功能类似于 STM32 的标准外设库。它的命名和 API 风格比较统一，比如IfxPort、IfxSpi、IfxCan、IfxAsclin等模块，对寄存器操作做了封装。用 iLLD 的时候，最忌讳直接上手就配置外设，而不关心初始化顺序。

以点灯工程为例，正常顺序是先关闭看门狗，然后初始化时钟、配置端口，再配置外设。ADC、CAN、SENT 这类外设还依赖特定的时钟源，你要先确认该外设的时钟分频是否已经使能。很多人把 SPI 初始化函数写在initLED前面，结果 LED 正常，SPI 却死活不出波形，查到最后是时钟门控没打开。

补充一个经验：iLLD 的库函数在不同芯片系列之间基本兼容，但个别寄存器位定义有差异。从 TC23x 移植代码到 TC375 时，不能想当然地复制整个文件，至少要把Ifx_Ssc_Pins这类结构体里的引脚编号、复用功能项核对一遍。官方例程在0_Src_0_AppSw里会给出不同开发板的 pin 配置，这是我看得最多的地方。

4. 调试技巧与翻车实录：从寄存器看问题，定位复位源

4.1 调试窗口使用经验：断点、变量、外设寄存器

ADS 的调试界面是基于 Eclipse 的 GDB 客户端，熟悉 STM32CubeIDE 的人应该不陌生。我调试 TC375 时最常用的不是断点，而是“外设寄存器窗口”。你可以在调试视图里打开Registers或Peripherals，直接查看MODULE_SCU、MODULE_PORT、MODULE_CCU6这些寄存器的实时值。相比于逐个读内存地址，这种方式直观很多。

打个比方，LED 点不亮时，我先看P00_PDISC是否禁用了数字输入功能，再看P00_IOCR0里的 PCx 位是否配置成了输出模式。如果寄存器值正确，才怀疑外部上拉或 LED 电路。如果没有寄存器窗口，你得对着 Reference Manual 找地址，再通过 Memory 窗口读值，效率低一倍不止。

变量监控方面，建议把全局变量加到Expressions窗口，并勾选“Suspend on peripheral access”之类的选项。TC375 是多核芯片，Cpu0、Cpu1、Cpu2 各自有独立的寄存器和变量上下文，调试时要选对线程。有时候你明明在 Cpu1 里改了一个全局变量，但在 Cpu0 的视图里刷新不出来，这是正常的，不要惊慌。

4.2 程序老是复位的排查思路

程序反复复位是 AURIX 开发里最折磨人的问题之一。现象是程序跑几毫秒就回到初始状态，断点根本停不住。这时候第一件事是看复位原因，TC375 的 SCU 模块里有复位状态寄存器，可以区分是上电复位、软件复位、看门狗复位还是处理器异常复位。

建议把复位状态打印出来，或者在调试器里手动读一下这个寄存器。如果值是看门狗复位，优先检查两个地方：一个是你有没有在启动阶段关闭或喂狗，另一个是芯片是否因为时钟失效触发了安全机制。TC3xx 的安全看门狗比较敏感，外部晶振抖动或者 PLL 配置导致时钟丢失，它都会主动拉复位。

还有一种情况是程序异常进入 Trap，Trap 在 TriCore 体系里类似 CPU 异常，但不会给你弹出HardFault_Handler这样的名字。调试器里 Trap 发生后 PC 会跳到异常处理代码，看起来像死循环。你可以在调试配置里打开 Trap 相关的断点事件，或者查看DCAI、DALIGN这类 CSP 寄存器的异常标记。遇到 Trap 优先查空指针访问和总线错误，AURIX 对非法地址访问非常敏感。

4.3 编译烧录高频报错速查

下面这个表是我在实际使用中踩过的高频报错，整理成速查表，方便你遇到问题时直接对号入座。

4.4 实际项目中建议稳定的工作流

环境搭好、能点灯之后，不要急着写业务逻辑。我建议你把手上的 TC375 开发板当作一个带串口和调试器的实验平台，先跑通几个关键外设：UART 打印、GPIO 输出、定时器中断。这相当于把 AURIX 的“心脏”和“血管”摸清了，后面写 CAN、以太网、SPI 外设时，只需要关注外设本身，不用再怀疑基础配置。

项目文件管理上，我倾向于把 ADS 工程和参考文档分开。ADS 工程放在独立工作区，参考手册、数据手册、原理图放在另一个阅读目录，一个软件问题往往会牵扯到 Linker Script、芯片数据手册、板级原理图三份资料，如果文件乱成一团，排查效率会直线下降。还有一个习惯是从官方例程复制代码而不是从零手写，AURIX 外设寄存器太多，手写出错的概率远高于你基于例程修改。

多核工程的启动顺序也是个经常踩的坑。TC375 上电默认只有 CPU0 会执行，CPU1 和 CPU2 需要你在代码里显式启动。官方模板里一般有IfxCpu_StartCore之类的调用，你要确保每个核都分配了独立栈和入口函数。如果 CPU1 起不来，优先查对应核的 CSA 和栈是否在 LSL 里定义了，否则访问非法地址会直接 Trap。

我在实际项目里最深的体会是：TC375 本身不复杂，复杂的是它同时集成了多核、功能安全、复杂外设和精细的电源时钟管理。很多调试问题本质上是“寄存器配置和手册不一致”，而不是编译器或 IDE 的问题。所以最后再分享一个小技巧——当你不知道某个外设为什么没反应时，先去翻芯片参考手册里对应模块的“Initialization Sequence”小节，照着上面的顺序配合 iLLD 的init函数一步步对照，十次里有八次能定位到问题。