英飞凌 Infineon 开发指南

编制日期 2026-10-14 ｜ 版本号 Rev 1.0

PSoC / XMC / TRAVEO / AURIX 四条产品线 —— 从「这四条线到底该选哪条」到「固件烧进去、能断点、能过功能安全审查」的一份工程手册

结论：英飞凌的横跨比想象中宽得多 —— PSoC 卖的是「可编程模拟 + CAPSENSE 触摸」， XMC 卖的是「工业功率与电机控制」，TRAVEO 卖的是「车身与区域控制」，AURIX 卖的是「带锁步核与 GTM 的汽车主控」。 四条线除了「都是英飞凌」这一点之外几乎没有可复用的东西：PSoC 走 ModusToolbox 图形化配置，TRAVEO/AURIX 走 AURIX Studio， XMC 是老牌 Eclipse 工程，AURIX 还有自己的 TriCore 调试器生态与 DSA/DAP 硬件。 真正让人卡住的从来不是代码，而是三件小事：PSoC 的引脚复用要在配置器里改而不是在代码里改、 AURIX 的中断优先级数值越小优先级越高（与 Cortex-M 相反）、下载器与芯片系列必须配对。 本文按「选型 → 装环境 → 建工程 → 编译 → 烧录 → 调试 → 外设 → 硬件 → 排障」的真实顺序组织，每一段都给可对照的表格、可复制的代码、以及该段最常踩的坑。

报告总结

英飞凌的官方资料分散在几个完全不同的站点上，而且不同产品线的资料风格差异极大： PSoC 侧继承 Cypress 的传统，文档里有大量「原理图式」的组件化说明；AURIX 侧则是典型欧系汽车习惯 —— 一本 2000 页的 User Manual、 一份独立的 Safety Manual、一份 AURIX Studio 的手册、还有一堆必须登录 myInfineon 才能下载的 Technical Reference。 网上的中文教程绝大多数停留在「装 IDE → 建工程 → 点下载」这一步，一旦遇到 ModusToolbox 找不到 BSP、 AURIX Studio 连不上 miniWiggler、TriCore 中断优先级配反了 就无解。本文档做了四件官方分散文档没做的事：

• 把四条线摆到同一张表上对比：明确说出「它们之间哪些东西能复用、哪些必须重写」，避免选错线之后才发现生态不通。
• 把内核差异写透：Cortex-M 的 NVIC 与 TriCore 的中断路由器（IR）在概念上完全不同，不讲清楚会一直用错心智模型。
• 把坑写在坑发生的地方：不单独罗列「常见问题」，而是在讲每个环节时就把该环节的失效现象、原因、处置一起给出。
• 明确标注哪些是定性描述：寄存器地址、位域名、向量号、等待周期这类精确数值，一律指向官方手册章节，不凭印象编。

读者路径

本文档共 20 章 + 4 个附录，按「先跑通、再理解」的顺序组织：

• 只想尽快跑通第一个程序：第 4 章（装 IDE）→ 第 5 章（建工程点灯）→ 第 7 章（烧录）→ 第 20 章（核查清单），四章足够。
• 还在纠结选哪条线：第 2 章有跨线对照表与决策路径，先看这两节能省掉几周返工。
• 从 STM32 切过来：第 18 章是专门的移植对照，先看这一章能省两三天。
• 调不通、报错：直接翻第 19 章故障排查速查表，按现象分层定位。
• 要写驱动：第 9 章 GPIO → 第 10 章 中断 → 第 11 章 时钟电源 → 第 12 章 外设 → 第 13 章 定时器。
• 做电机控制：第 15 章（GTM + FOC 信号路径）+ 第 13.2 节（GTM / CCU6 / CCU8 对照）。
• 做汽车电子：第 3 章（TriCore 与锁步核）→ 第 16 章（功能安全）→ 第 17.2 节（多电源与 Power Stage）。
• 做低功耗产品：第 11.4 节与第 16 章，注意「进低功耗后调试口可能失去连接」这件事。

1 · 文档导读与阅读路径

这一章说明本文档的边界：覆盖什么、不覆盖什么，以及为什么把内容按「流水线」而不是按「功能模块」组织。

1.1 覆盖范围

本文档覆盖从「拿到一块板子」到「固件跑起来、能在断点处停下来、并能量产烧录」的完整链路，四条产品线各自成篇：

• 选型（第 2 章）：PSoC 3 / 4 / 6、PSoC 4M、XMC1000 / 4000 / 7000、TRAVEO T2G / T2G-E、AURIX TC2x / TC3x 的定位、 资源档位与跨线对照，以及 EB tresos / ModusToolbox / AURIX Studio 的分工。
• 内核与架构（第 3 章）：Cortex-M0+ / M4F / M7F 与 TriCore 1.6 / 1.8 的差异，TriCore 的 CPU + SCU 多核结构、 Trap 与 Service Call 机制、AURIX TC3x 的锁步核与 CSA 分布式共享区、GTM 定时器模型。
• 环境与工程（第 4~6 章）：五套 IDE 的定位与安装要点、工具链构成、ModusToolbox 的 Makefile + CMake 构建体系、 启动代码与链接脚本、AURIX 的 linker script 与 CSA 内存布局。
• 烧录与调试（第 7~8 章）：Mini-Wiggler / DAP / DAPU 硬件、Infineon Programmer、XMC 的 uTool、 AURIX 的 DAS 与 UDS OTA 量产通道、安全与加密等级；ModusToolbox Debug / SEGGER Ozone / UDE 示波器式调试 / TRACE32、多核同时调试。
• 外设与内核细节（第 9~16 章）：GPIO 与端口路由、中断系统（NVIC 与 TriCore IR 双视角）、时钟复位电源、 SCB / Tcu / USART / SPI / IIC / ADC / DMA、定时器 / PWM / RTC / 看门狗、CAN / Ethernet / USB / HSM、GTM 与电机控制、低功耗与功能安全。
• 硬件、移植与排障（第 17~20 章）：电源分区与去耦、AURIX 多电源与 Power Stage 选型、复位与晶振、 调试口与差分走线；从 STM32 移植的改动清单；按现象分类的故障排查速查表；四类核查清单。

1.2 不覆盖什么

以下内容超出本文档范围，需要时请查阅对应官方资料：

• 寄存器位域全集：AURIX TC3xx 的 User Manual 有两千页量级，PSoC 6 的 Technical Reference 也有上千页。 本文档只给关键模块的常用寄存器组与「去手册里查哪一章」，写代码时仍需对着手册核一遍。
• AUTOSAR 架构本身：MCAL / BSW 的层定义、BSW 配置流程、DBC 与 ARXML 的映射规则属于 EB tresos Classic 平台与 Vector/EB 工具链的文档范围。本文只在 2.7 节讲清楚它与 IDE 的分工边界。
• 电机控制算法本身：FOC / 观测器 / 磁场定向控制的数学推导不属于本文档。本文覆盖的是跑这些算法需要的硬件资源、 信号路径与调试手段（第 15 章）。
• 协议栈细节：TCP/IP、USB 协议栈、CAN 上层协议（UDS / DoIP / SOME/IP）的报文格式与状态机， 本文只覆盖它们依赖的硬件接口与 DMA/中断链路。
• 每一款封装的完整管脚定义：附录 A 只列最容易搞错的调试、自举、电源与高速接口引脚，完整管脚表请查对应 DS。
• 具体数值型电气参数：电流消耗、上升时间、ESD 等级、结温范围这类参数随器件与封装变化， 本文一律给出「查哪张表」的指引而不是抄一个数字，避免文档过期后误导设计。

1.3 命名约定与术语表

英飞凌的料号命名分两套体系 —— 传统 MCU 线（PSoC / XMC / TRAVEO）与 AURIX 完全不同， 这是第一次接触时最容易搞混的地方：

1.4 事实来源与免责

本文档的架构性描述（内核、模块划分、工具链分工、选型逻辑）来自英飞凌官方产品页与开发者社区的公开资料； 数值型信息（主频、Flash/SRAM 容量、核心数、外设数量）在正文中出现时会指明出处章节或产品页。 本次撰写时的主要依据如下：

2 · 四大产品线全景与选型

英飞凌的 MCU 业务横跨消费、工业、汽车三层，每层的产品线定位、内核与生态都不一样。这一章先把货架摆在桌子上， 讲清每条线的存在理由、跨线对照关系，以及「线内选型」和「线间选型」是两件事。

2.1 四条产品线，一句话认识

来源：infineon.com 各产品线产品页 + AURIX TC3xx 产品手册

2.2 PSoC：可编程模拟数字 + CAPSENSE

PSoC 是英飞凌收购 Cypress 后最有辨识度的产品线。它的技术路线不是「外设越多越好」，而是把外设本身做成可配置的硬件： 用 UDB（Universal Digital Block）拼自定义逻辑，用可编程模拟阵列（CTB / Opamp / Comparator / ADC）搭模拟前端， 用 CAPSENSE 做电容式触摸。这带来一个直接后果：PSoC 的引脚功能不是在代码里配的，而是在配置器里定的。

PSoC 6 的双核是它相对 PSoC 4 最大的架构变化：ModusToolbox 3.0 起支持双核工程与两核同时调试。 低功耗核（Cortex-M0+）通常承担蓝牙/BLE 协议栈栈底、常驻采样与唤醒职责，高性能核（Cortex-M4F）跑应用。 这带来一个工程上的好处：可以在低功耗核上跑一个几乎不占动态功耗的常驻任务，主核整段时间可以睡在 Deep-Sleep 里。

2.3 XMC：工业功率与电机控制

XMC 面向工业，核心卖点是功率电子与电机控制的外设组合。CCU4（捕获比较单元 4）负责输入捕获与 PWM， CCU8 负责更复杂的定时与 ADC 同步，ERU（Event Request Unit）做外设间的事件路由 —— 这三件套构成了数字电源与 FOC 的经典架构。

XMC 家族有一个常被忽略的优势：Flash 从 16 KB 到 2 MB、RAM 从 8 KB 到 352 KB 全档位覆盖， 从 16 脚 TSSOP 到 196 脚 LFBGA 都有。做电机控制时最舒服的是 XMC4000 的 M4F + DSP/SFPU —— 这在 Arm 生态里与 STM32F4 是同一档，但在 XMC 上还额外带 CCU8 与功率级相关的资源。

2.4 TRAVEO T2G / T2G-E：车身与区域控制

TRAVEO 是英飞凌的汽车产品线，T2G 是第二代 32 位 Arm Cortex 产品。它的定位是车身与区域控制 —— HVAC、座椅控制、门控、TPMS 传感器、网关、区域控制器（Zonal Controller）与车身控制模块（BCM）； 另有一条 Cluster 子线（CYT2C / CYT3D / CYT4D）专门做仪表盘、HUD 与矩阵式 LED 前灯控制。

2.5 AURIX TC2x / TC3x：汽车主控

AURIX 是英飞凌的汽车主控平台，用的是自研的 TriCore 内核。它的定位与前三条线都不同： 不是通用 MCU，而是面向 ASIL-D 的功能安全平台。理解 AURIX 只需要抓住三个特征：

• 多核 + 锁步核：一个芯片里有多个 TriCore CPU，其中部分成对部署为「锁步对」—— 两个核执行相同指令流并逐周期比对结果，不一致就立即触发告警。这是 ASIL-D 的硬件基础。
• GTM（Generic Timer Module）：一个专为电机与功率电子设计的定时器模块， 它能把「PWM 生成 + ADC 触发 + 换相逻辑」做成硬件闭环，不需要 CPU 参与。
• Mirrored Flash 与 A/B 分区：Flash 有镜像 Bank 结构，支持 A/B 分区 OTA 与安全启动。

TC3xx 官方产品手册给出了一张非常有用扩展矩阵，把整个家族按「性能 / Flash / 引脚兼容性」三个维度串起来： 从 1 核 160 MHz 的 TC32x，到 2 核的 TC3Ax / TC3Bx、3 核的 TC36x / TC37x、4 核的 TC38x， 一直到 6 核 300 MHz 的 TC397x / TC399x。同一代封装内引脚兼容，这意味着平台化设计可以在一个 PCB 上做多档配置。 TC39x 的官方页面还列出了它的连接性清单：1 GbE、FlexRay、12 路 CAN（含 CAN FD）、25×SENT、6×QSPI、eMMC/SDIO 等。

2.6 跨线选型对照表

2.7 软件生态分工：EB tresos / ModusToolbox / AURIX Studio

英飞凌的工具链看起来很多，但分工是清晰的：ModusToolbox 是 PSoC / XMC / TRAVEO 的主入口， AURIX Studio 是 AURIX 的主入口，EB tresos 是 AUTOSAR 配置层的专用工具。三者不互相替代。

2.8 选型决策路径

把上面这些收敛成六个问题的决策树，从上往下问，命中即停：

补充三条不成文经验：

• 先定「线」，再定「型号」，最后才看外设。因为四条线之间连代码都不能直接搬， 反过来先按外设清单选型，很容易选到一条生态对你完全陌生的线。
• 汽车项目优先考虑 AURIX，除非只是车身小节点。AURIX 的锁步核、Mirrored Flash、GTM 与安全手册是 功能安全的落地条件；TRAVEO 适合车身与区域控制这类不需要 GTM 的场景。
• PSoC 项目要接受「配置器驱动」的开发方式。如果你打算完全用代码写寄存器， PSoC 的价值会打折一半 —— 它省下的时间是通过配置器省出来的，不是通过手写寄存器省出来的。
• 第一次接触某条线，买官方评估板而不是最小系统板。官方板自带板载调试器 （PSoC 的 DAP / AURIX 的 miniWiggler），能省掉一半的连接类故障排查。

3 · 内核与架构差异

英飞凌的两条内核路线差别不在「性能」，而在异常模型、中断控制器位置、上下文保存方式。 用 Cortex-M 的直觉去写 AURIX 代码，最可能的结果不是编译报错，而是「能跑但优先级全反」这种隐性错误。

3.1 两代内核谱系

来源：TriCore TRM + 英飞凌开发者社区 TriCore 中断与向量表系列

3.2 TriCore 的 CPU 与 SCU

来源：英飞凌开发者社区《Aurix/Tricore 中断与向量表》+ TC3xx 中断系统技术文章

AURIX TC3xx 的芯片内部可以粗略分成四类东西，写代码时必须知道「我要改的东西属于哪一类」：

多核场景下还有一个概念必须分清：IR 与 SRC 是全芯片一套的， 所以「谁响应这个中断」是通过 TOS（服务类型）字段选的； 而 ICR 是每核一份，所以「这个核要不要开中断」是本核自己的开关。 配中断时两个都要配 —— 只设了 SRC 的 SRE 而没设本核 ICR 的 IE，现象是「中断永远不进来」； 反过来只开了 ICR 的 IE 而没设 SRE，现象是「进了中断但不知道是谁触发的」。

3.3 Trap 与 Service Call

TriCore 有两套「主动进入内核」的机制，用途完全不同：

3.4 AURIX TC3x 的锁步核

锁步（lockstep）是 AURIX 拿到 ASIL-D 的核心硬件手段。以 TC39xXA 为例， 官方产品页给出的规格是 「6 核 / 4 锁步核、300 MHz」，并写明 「除本机可用核心外，额外的 4 个 checker 核提供约 4000 DMIPS 的等效检测能力」， 以及「Diverse lockstep architecture 降低 ASIL-D 系统的开发成本」。 另外还有一条很实用的说法：「同一封装内可选择单核或锁步核心」。

3.5 GTM 定时器模型

GTM（Generic Timer Module）是 AURIX 在电机与功率电子方向的王牌，也是 TRAVEO T2G 在电机应用里会用到的同类资源。 它的设计思路与「一个定时器一个通道」的常规定时器完全不同：GTM 是一个模块，内部有多个子单元， 各子单元分别负责 PWM 生成、输入捕获、ADC 触发与时钟分发，彼此之间用内部信号矩阵互联。

GTM 最重要的价值是把「采样—换相」闭环放进硬件：CMU 定时触发 ATOM 输出 PWM， 同时经 ADCR 触发 ADC 采样，采样结果通过 DMA 或直接由 CPU 读取 —— 整个环路不需要 CPU 参与定时判断。 这既是低抖动 PWM 的来源，也是「没有 CPU 也能安全输出」的功能安全基础。详见第 15 章。

3.6 内存模型：MPU、缓存与 CSA

来源：TriCore TRM 的 Trap / CSA 章节 + TC3xx 中断系统技术文章

AURIX TC3xx 的内存保护是两层机制，这一点与 Arm 系的 MPU + TrustZone 概念相近但实现不同， 是 AURIX 混合关键性平台（mixed-criticality）的技术基础：

CSA 方面还剩两个必须记住的工程点：

• CSA 是静态分配的，不存在「栈溢出会自动扩展」。链接脚本里 CSA 段的深度就是实际深度。 用完的表现不是报错而是随机跑飞 —— 这是 AURIX 项目最典型的「玄学 bug」来源之一。
• 锁步核需要成对且对称的 CSA 配置。链接脚本里两个核的 CSA 段必须声明成一致的形态， 否则硬件一致性检查会持续报错。这也是 AURIX 工程模板里 CSA 段常写成「成对声明」的原因。

4 · 开发环境

英飞凌的工具链不是「一个 IDE + 一个编译器」，而是分层供应的若干个包。这一章讲清每个包干什么、 装的时候出什么错，以及版本之间的兼容关系。

4.1 五套 IDE 的定位与分工

把「五套 IDE」按产品线对齐，就一目了然了：

工具链是分层供应的，下层出问题会以「上层的怪症状」表现出来。记住这个分层，排查时就能自下而上缩小范围：

4.2 ModusToolbox 安装要点

ModusToolbox 3.x 的安装用官方的 ModusToolbox Setup 程序完成，这是一个需要联网的在线安装器， 按需拉取核心工具包与可选功能包（feature packs）。安装与配置要点：

1. 优先用 Setup 程序装，不要手工拼包。官方明确把 Setup 程序作为推荐安装方式， 它会顺带处理补丁与功能包之间的版本依赖；手工拼包容易出现「编译器版本和 BSP 不匹配」。
2. 注意 Eclipse 的版本对应关系。ModusToolbox 3.2 把内置 Eclipse IDE 升到了 Eclipse Platform 4.28， 并支持在 Windows 11 上与 Modus-Shell 集成。较新的发行说明里 Eclipse 已经从 ModusToolbox 主包中拆分成可单独安装的组件， 通过 Setup 程序按需取用。
3. 工具链作为独立包提供。官方发行说明写明 Arm GCC 11.3 与 GCC 14 作为独立包由 Setup 程序提供， 按需要选择安装。这带来一个好处：编译器版本与工具包版本解耦， 换编译器不必重装整个 IDE。
4. macOS Intel 平台已不受支持。发行说明里明确写了 Eclipse 在 Intel Mac 上调试不可用并不再支持， 建议改用其它 IDE（如 VS Code）。选工具前先确认自己机器架构。
5. 优先考虑 VS Code。官方发行说明在多处推荐 VS Code 作为替代 IDE， 并支持在 Eclipse 里挂 Clangd 做代码分析。团队里有人用 VS Code 时可以直接走这条路。

4.3 AURIX Studio 与 Traveo IDE

AURIX Studio 是英飞凌基于 winIDEA 做的免费 IDE，定位是「非商用免费」。它的能力边界必须说清楚：

AURIX Studio 的工程是「Example Workspace」式的 —— 官方文档里新建工程的入口就是 新建一个工作区或选择一个 Example Workspace，然后在 Hardware | Debugger Hardware | Hardware Type 里把硬件类型选成 Infineon DAP miniWiggler。 这与 PSoC 那种「向导新建空工程」的体验差别很大，建议 AURIX 项目直接从官方 Example Workspace 改， 而不是从零建工程。关于 Traveo IDE：它面向 TRAVEO T1/T2G 的早期世代， 新一代 T2G 越来越多以 ModusToolbox 为主，两者处于并存期，新建项目建议先查官网当前主推哪一套。

4.4 工具链构成

「工具链」在英飞凌语境下通常指这几样，装之前先确认版本配对：

4.5 常见安装故障

5 · 第一个工程：从新建到点亮 LED

这一章的目标是把「能跑通」这件事变成可复制的流程。四条产品线的第一步动作不一样， 但验收标志完全相同：断点能停在 main() 入口。

5.1 PSoC：用 ModusToolbox 新建工程

1. 新建 Application Project：选择目标器件（器件名形如 CY8C6xxx）， 勾选对应的 BSP（Board Support Package）。BSP 决定了这个工程默认按哪块板的时钟与引脚配置来初始化。
2. 选应用模板：第一次建议用「Empty Application」或最小模板， 不要一上来就用带蓝牙的模板 —— 模板越复杂，出问题时越难定位。
3. 配置时钟与引脚：在 Configurators 里定系统时钟频率、定要用的引脚及其功能。 这一步是 PSoC 与其它三条线最大的区别：引脚功能在这里定，不在代码里定。
4. 生成代码：Configurators 会生成 design.cycfg 对应的初始化代码、 以及设备配置表。这一步没跑通，后面全是错的。
5. 编译：ModusToolbox 用 make 构建体系，产出 .elf / .hex / .map。
6. 烧录与调试：选好调试器（板载 DAP 或独立调试器）后，先 Launch 到 main() 打断点验证。

5.2 PSoC：用 PSoC Creator 新建工程

车规 PSoC 4 / 4M 的官方文档仍然以 PSoC Creator 为主，它的交互模型是「原理图 + 固件协同」： 你在图形界面上摆组件、连线、赋引脚，工具同时管理硬件配置与代码生成。

5.3 TRAVEO / AURIX：用 AURIX Studio 新建工程

AURIX 侧的第一步不是「新建空工程」，而是从官方 Example Workspace 起步。官方文档里新建流程写得很明确： 新建一个工作区，或选择一个 Example Workspace。

1. 准备调试器：把 Infineon DAP miniWiggler 连到 PC 与目标板。Linux 上还需要额外装 FTDI 驱动。
2. 新建 / 打开工作区：在 AURIX Studio 里新建工作区，或从示例选择一个。
3. 选择硬件类型：Hardware | Debugger Hardware | Hardware Type → Infineon DAP miniWiggler。 若有多个 miniWiggler，可在 Configure 里指定要连哪个以及会话名。
4. 确认编译器：AURIX Studio 需要配合 TriCore 编译器（TASKING 或 HighTec）使用， 这一层与 PSoC 的 Arm GCC 是完全独立的。
5. 编译并下载：编译示例，确认能下载。
6. 打断点验证：在 main() 或应用入口打断点，Run。能看到变量值就说明调试链路通了。

如果是 TRAVEO T2G：官方工具页把 ModusToolbox 与 AURIX Studio 都列为可用工具， 同时 EB tresos 提供 MCAL（官方有专门的 AN 文档《Getting started with T2G MCAL using TRAVEO T2G MCU》）。 做 T2G 建议先看它挂的是哪套工具的官方教程，按那套走，能省掉大量版本与配置器差异的困惑。

5.4 点亮 LED：PSoC 路径

PSoC 点灯的代码本身很短，难点在于引脚在配置器里怎么定。下面是一个概念性模板， 具体宏名以所用 PDL 版本与目标器件为准：

/* ---------- 前提：LED 引脚已在 Configurators 中配置为 GPIO 输出 ---------- */
/* 在 Configurators 里做三件事：
   1. 选一个引脚（如 P0_3）并设为 GPIO 输出（初始电平按 LED 接法选）
   2. 确认该引脚所在端口的驱动能力与电压域（VIO / VDD）
   3. 重新生成代码，让 design.cycfg 与生成的初始化代码生效
*/

/* ---------- 方式一：直接写 GPIO 寄存器（最贴近硬件，最不容易踩配置坑） ---------- */
#define LED_PIN    3u
#define LED_PORT   P0_BASE

void led_init(void)
{
    /* 让引脚成为 GPIO 输出：清除方向选择位（寄存器命名以目标器件 RM 为准） */
    *(volatile uint32_t *)(LED_PORT | REG_GPIO_PINSEL) &= ~(1u << LED_PIN);
}

void led_write(bool on)
{
    uint32_t data = *(volatile uint32_t *)(LED_PORT | REG_GPIO_DATA);
    if (on) { data |=  (1u << LED_PIN); }
    else   { data &= ~(1u << LED_PIN); }
    *(volatile uint32_t *)(LED_PORT | REG_GPIO_DATA) = data;
}

/* ---------- 方式二：用 PDL 的 GPIO 封装（可读性更好） ---------- */
void led_init_pdl(void)
{
    const Cy_GPIO_CfgPortPin cfg = {
        .pin     = CY_GPIO_PIN_3,
        .mask    = CY_GPIO_PIN_3_MASK,
        .drvMode = CY_GPIO_DM_PU200,
        .outVal  = 0u,
        .drive   = CY_GPIO_DRIVE_STRONG,
    };
    Cy_GPIO_Pin_Init(CY_GPIO_PRT0, &cfg);
}

void led_toggle_pdl(void)
{
    Cy_GPIO_Pin_Flip(CY_GPIO_PRT0, CY_GPIO_PIN_3);
}

/* ---------- 主循环：1 Hz 闪烁 ---------- */
void loop(void)
{
    for (;;)
    {
        led_toggle_pdl();
        CyDelay(500);          /* PSoC 6 有 CyDelay；也可用 PSoC 的定时器做非阻塞延时 */
    }
}

5.5 点亮 LED：AURIX 路径

AURIX 点灯要把三件事都对上：端口方向寄存器、引脚复用归属、该引脚所在的电源域。 AURIX 的引脚复用归属由 SCU 的 PPS（Port Pin Select）寄存器控制 —— 这与 PSoC 的 PINSEL 是同一个思路， 但位布局与复位默认值不同，务必对着手册写。

/* ---------- AURIX：GPIO 输出（GPIO 基地址与端口号以目标型号手册为准） ---------- */
/* 关键点：先确认引脚的复用归属是「GPIO」而不是某个外设，否则写了 P.OUT 也不会生效 */

#include "IfxReg.h"

#define LED_PORTOUT   0xF003C000u      /* 端口输出寄存器（示例值，见附录 C） */
#define LED_POMASK    0xF003C010u      /* 引脚掩码：哪些引脚是GPIO           */
#define LED_OUT       0x00010000u      /* 示例：选中的第 16 位引脚           */

static inline void led_init(void)
{
    /* 1. 把引脚切到 GPIO 归属：清掉复用选择位（位含义与复位值查手册） */
    MODULE_SCU.PPS[LED_PORT].IN = 0u;

    /* 2. 设置输出方向与驱动能力 */
    MODULE_SCU.PORT[LED_PORT].OMR = LED_OUT >> 16u;   /* OMR 高半字置位 = 置为输出 */
    MODULE_SCU.PORT[LED_PORT].OMR = 0u;

    /* 3. 清输出（LED 灭） */
    MODULE_SCU.PORT[LED_PORT].OUT = 0u;
}

static inline void led_toggle(void)
{
    /* OMR 是「原子置位/复位」寄存器：写 1 置位、写 0 复位，无需读改写 */
    MODULE_SCU.PORT[LED_PORT].OMR = LED_OUT;
}

/* ---------- 用 GTM 做 1 Hz 闪烁（推荐做法）---------- */
/* AURIX 上做 1 Hz 闪烁，推荐用 GTM 的 TOM/ATOM 输出一个方波，CPU 完全不参与。
   这既是低抖动 PWM 的来源，也是功能安全里「无 CPU 也能安全输出」的做法。详见第 15 章。*/

/* ---------- 注意：调试期间的栈与 CSA ---------- */
/* AURIX 的 CSA 链是静态分配的，示例工程里通常只给很浅的 CSA。
   如果你要在 main 里放大的局部数组，先检查链接脚本里的 CSA 深度。
   典型现象是「小工程正常，加了 buffer 就随机跑飞」—— 见 3.6 节。*/

5.6 第一个工程的验收标志

不要用「LED 亮了」当作唯一验收标志 —— 它同时可能是偶然的。按下面这五条逐条打勾，全过才算环境真的通了：

第 4 条最容易被跳过，也最能暴露问题 —— 很多「LED 正好在闪」的案例其实是时钟配置没成功， 用了复位默认频率，而 LED 的周期恰好看起来差不多。养成「读回寄存器确认」的习惯， 后面调 UART 波特率、ADC 采样率时会省下大量时间。