简介：这份资源是英飞凌 AURIX TC37x 系列微控制器的官方用户手册英文版，面向从事汽车电子、工业自动化与嵌入式硬件开发的 MCU 工程师及单片机学习者，用于系统理解该款高性能器件的架构、配置与使用方法。压缩包内共 1 个 PDF 文件，约 4.9MB，为完整版用户手册，便于离线查阅与检索。目前已有 987 人学习下载，在嵌入式硬件圈内具备一定参考热度。手册内容覆盖内存映射（MEMMAP）章节，从整体架构概览、功能描述到段划分、SRI 总线与 SPB 服务总线均有展开，并附修订记录；同时包含 TC37x 固件、片上系统连接与桥接、特定 IP 配置及寄存器集等模块，目录层级清晰，可快速定位外设接口、时钟系统、调试接口与安全特性等细节。对于需要熟悉 TC37x 功能边界、规划底层驱动或排查硬件配置问题的开发者，这份文档可作为与家族资料配合使用的补充参考，帮助建立完整的寄存器与内存布局认知。

1. 拿到 TC37x 手册先别翻目录：这份 2020 年 V1.6.0 的补充文档到底补了什么

如果你手上有一块 AURIX TC37x 的板子，或者正在做 MCU 单片机嵌入式硬件选型，大概率已经踩过同一个坑：家族手册翻了几百页，寄存器地址对不上，内存段划分和实际芯片差一截。这份 2020 年 8 月发布的 V1.6.0 用户手册，定位很明确——它不是从零讲 TC37x 的教科书，而是家族文档的补充册，专门把 TC37x 这个型号特有的 IP 配置、寄存器集、连接关系单独拎出来讲清楚。换句话说，家族手册告诉你 AURIX 架构长什么样，这份文档告诉你 TC37x 这一颗芯片哪里不一样。它适合已经能跑通基础工程、需要对着寄存器做底层配置的嵌入式硬件和底层软件工程师，不适合刚接触单片机、连时钟树都没配过的新手直接啃。全文按内存映射、固件检查、片上互联、CPU 子系统、NVM、LMU、DAM、SCU、时钟、电源管理、MTU、端口这些模块逐章展开，每一章都带 Revision History，这一点后面会专门讲怎么用。

2. 内存映射与总线结构：先搞清楚地址从哪来

2.1 MEMMAP 章节的读法：Segments 和两套总线

第 2 章 Memory Maps 是整份文档里最该先读的部分，因为它决定了你后面所有寄存器访问的基地址从哪来。这一章先给 Overview，再进 Functional Description，然后拆成 Segments、Bus Fabric SRI、Bus Instance SPB 三块。Segments 讲的是内存分段，也就是代码、数据、外设寄存器各自落在哪个地址区间；SRI 是系统资源接口总线，负责把 CPU 核和内存、外设连起来；SPB 是服务外设总线，偏控制和低速外设通信。实际配置时最常见的翻车是拿家族手册的段地址直接写 TC37x 的链接脚本，结果程序跑飞——因为 TC37x 的段划分在补充文档里单独列了，必须以此为准。

读这一章我一般会做一件事：把 Segments 小节里的地址区间抄成一张表，和链接脚本里的 MEMORY 段一一对照。下面是一个对照用的脚本片段，用来把手册里的段信息落成可检查的配置：

# 从手册 Segments 小节抄出的段信息，整理成链接脚本可用的格式 # 注意：地址和长度必须逐字对照 V1.6.0 第 2 章，不要用家族手册的值 cat > tc37x_mem_check.ld <<'EOF' MEMORY { /* 程序段：对照手册 Segments 小节的代码区 */ pflash (rx) : ORIGIN = 0x80000000, LENGTH = 0x200000 /* 数据段：对照手册 Segments 小节的数据区 */ dsram (rw) : ORIGIN = 0x70000000, LENGTH = 0x10000 /* 外设寄存器区：SRI/SPB 挂载的寄存器空间 */ peri (rw) : ORIGIN = 0xF0000000, LENGTH = 0x10000 } EOF

这段脚本本身不复杂，关键在于 ORIGIN 和 LENGTH 两个参数必须来自手册第 2 章的 Segments 描述，而不是凭经验填。逻辑说明：链接脚本的 MEMORY 块决定了链接器把哪段代码放到哪个物理地址，地址错了，启动时取指就会落到非法区域。参数说明：pflash 的 rx 表示只读可执行，dsram 的 rw 表示可读写，peri 区一般只做寄存器映射不做代码存放。改的时候只动 ORIGIN 和 LENGTH，属性别乱改。

2.2 SRI 与 SPB：两套总线别混着配

Bus Fabric SRI 和 Bus Instance SPB 是两种不同角色的总线，文档把它们分开讲是有原因的。SRI 面向高带宽的主从连接，CPU 取指、DMA 搬数据走这条；SPB 面向外设寄存器的低速访问。实际做底层驱动时，如果你把一个高频访问的外设挂在 SPB 上还指望它跑出高吞吐，那就是选型层面的错误，不是代码能救的。判断方法很简单：看手册里该外设的 Connectivity 小节挂在哪个总线下，再决定访问策略。SRI 上的访问可以做批量、可以做缓存优化，SPB 上的访问更适合单次寄存器读写、避免频繁轮询。

这里有个血泪经验：调试时用调试器读某个外设寄存器读不到值，先别怀疑芯片坏了，去第 4 章 On-Chip System Connectivity 里查这个外设的 slave interface 挂在哪。文档 4.3.1 专门讲了 sri slave interface，4.5.1 讲了 Domain 0 Interconnection Matrix，这两处合起来就是一张“谁能访问谁”的关系图。把这张图搞清楚，比盲目试寄存器地址高效得多。

3. 固件检查与寄存器配置：把文档变成可执行的初始化代码

3.1 TC37x Firmware 章节的 Checker 输出怎么用

第 3 章 TC37x Firmware 里有一个很实用但容易被跳过的点：3.1 节 Checker Software exit information for ALL CHECKS PASSED。这说的是固件自检软件在全部检查通过时的退出信息。很多人拿到板子先跑例程，跑通了就往下走，从来不确认自检到底过没过。我的习惯是先把这一节的退出信息对照一遍，确认自检流程真的走到了 ALL CHECKS PASSED 这个状态，再开始改代码。因为如果自检阶段就有隐患，后面调外设调半天可能都是在错误的基础上打转。

具体做法是：在启动流程里加一段自检结果读取，把退出信息打印或存到固定内存位置，上电后第一时间确认。下面是一个读取自检状态并做判断的示意代码：

/* 读取固件自检退出信息，对照手册 3.1 节的 ALL CHECKS PASSED 状态 */ #include <stdint.h> #define CHECKER_EXIT_REG (*(volatile uint32_t *)0xF0000100U) /* 地址按手册 3.1 节实际值替换 */ #define CHECKER_PASS_CODE 0x5A5A5A5AU /* 通过码按手册定义替换 */ int checker_selftest_ok(void) { uint32_t exit_info = CHECKER_EXIT_REG; /* 只有等于手册定义的通过码，才认为自检全部通过 */ if (exit_info == CHECKER_PASS_CODE) { return 1; } /* 不通过时保留原始值，方便调试器里直接看 */ return 0; }

逻辑说明：这段代码在启动早期读自检退出寄存器，和手册定义的通过码比对，返回布尔结果供后续流程判断。参数说明：CHECKER_EXIT_REG 的地址和 CHECKER_PASS_CODE 的具体值都必须以手册 3.1 节为准，我这里用占位值是为了说明结构，实际填的时候逐字核对。注意：不要把这个判断放在中断里做，自检结果要在主流程初始化阶段确认，避免时序干扰。

3.2 寄存器集章节的通用套路：Specific Register Set 怎么读

从第 4 章开始，几乎每一章都有 TC37x Specific Register Set 和 TC37x Specific Registers 两个小节，这是整份文档出现频率最高的结构。读法有套路：Specific Register Set 给的是寄存器集合的概览和偏移，Specific Registers 给的是逐个寄存器的位域描述。实际写驱动时，先看 Set 确认有哪些寄存器、偏移多少，再看 Registers 确认每个位的含义和复位值。这个顺序别反，反了容易在几百个位域里迷路。

以第 4 章 FPI Bus Control Units (SBCU) 为例，4.7.2 是 SBCU Control Unit Registers，下面又拆成 4.7.2.1 SBCU Control Registers Descriptions 和 4.7.2.2 SBCU OCDS Registers Descriptions。做总线控制配置时，先定位到具体寄存器，再按位域拼值。下面是一个按位域配置寄存器的写法示例：

/* 按手册位域描述配置 SBCU 控制寄存器，避免整字写入误改保留位 */ #include <stdint.h> #define SBCU_CTRL_REG (*(volatile uint32_t *)0xF0000200U) /* 偏移按手册 4.7.2 节替换 */ /* 位域定义：字段名和位宽严格对照手册 4.7.2.1 的描述 */ #define SBCU_CTRL_EN_POS 0U #define SBCU_CTRL_EN_MSK (0x1U << SBCU_CTRL_EN_POS) #define SBCU_CTRL_MODE_POS 4U #define SBCU_CTRL_MODE_MSK (0x3U << SBCU_CTRL_MODE_POS) void sbcu_ctrl_init(void) { uint32_t tmp = SBCU_CTRL_REG; /* 先清目标位域，再按手册要求的值写入，保留其他位不动 */ tmp &= ~(SBCU_CTRL_EN_MSK | SBCU_CTRL_MODE_MSK); tmp |= (1U << SBCU_CTRL_EN_POS); /* 使能，值对照手册 */ tmp |= (0x2U << SBCU_CTRL_MODE_POS); /* 模式选择，值对照手册 */ SBCU_CTRL_REG = tmp; }

逻辑说明：读-改-写是配置带保留位寄存器的标准做法，先读出当前值，清掉要改的位域，再写入新值，避免把没定义的位写成意外值。参数说明：POS 是位起始位置，MSK 是掩码，这两个都必须和手册位域表逐位对齐；使能值和模式值不要凭经验填，手册写多少就是多少。注意：如果寄存器有写保护或需要解锁序列，手册会在寄存器描述里注明，配置前先确认。

4. 存储子系统与系统控制：NVM、LMU、DAM、SCU 的配置边界

4.1 NVM 与 DMU：非易失存储操作的时序约束

第 6 章 Non Volatile Memory (NVM) Subsystem 和第 6.3 节 Data Memory Unit (DMU) 是擦写操作的核心参考。NVM 章节先给 Overview，再进 DMU 的寄存器集和寄存器描述，6.3.2.1 还专门给了 SRI slave interface 的寄存器地址空间。做 Flash 擦写驱动时，最容易翻车的地方不是命令序列写错，而是时序参数没按手册来。擦除和写入都有最小间隔、最大等待时间这些约束，手册在寄存器描述里会给出具体数值，这些数值不能靠试。

我的做法是把手册里的时序参数抽成一张表，写进驱动配置结构体，而不是散落在代码各处。下面是一个把时序参数集中管理的结构体示例：

/* NVM 擦写时序参数集中管理，数值逐项对照手册第 6 章寄存器描述 */ #include <stdint.h> typedef struct { uint32_t erase_timeout_us; /* 擦除最大等待时间，按手册填写 */ uint32_t write_timeout_us; /* 写入最大等待时间，按手册填写 */ uint32_t erase_retry_max; /* 擦除重试次数上限，按手册建议填写 */ } nvm_timing_t; /* 初始化时从手册抄来的参数，改芯片型号必须重新核对 */ static const nvm_timing_t g_nvm_timing = { .erase_timeout_us = 0, /* 占位，按手册第 6 章实际值替换 */ .write_timeout_us = 0, /* 占位，按手册第 6 章实际值替换 */ .erase_retry_max = 0, /* 占位，按手册建议值替换 */ }; int nvm_wait_erase_done(volatile uint32_t *status_reg) { uint32_t waited = 0; /* 轮询状态位，超过手册给出的最大等待时间就判失败 */ while ((*status_reg & 0x1U) == 0U) { if (++waited > g_nvm_timing.erase_timeout_us) { return -1; } } return 0; }

逻辑说明：把超时和重试参数集中成常量结构体，好处是换型号或手册改版时只改一处，不会漏改。参数说明：三个字段的数值全部来自手册第 6 章对应寄存器的描述，我这里留占位是因为不能编造具体数值，实际使用时逐项填入。注意：轮询等待要有上限，没有上限的 while 循环在擦除失败时会卡死整个系统，这是嵌入式里很典型的黑匣子问题。

4.2 LMU、DAM 与 SCU：局部内存和系统控制的配置顺序

第 7 章 Local Memory Unit (LMU)、第 8 章 Default Application Memory (DAM)、第 9 章 System Control Unit (SCU) 这三章连起来看，能理清一个配置顺序问题：局部内存和默认应用内存的初始化，要在系统控制单元的相关配置之前还是之后？文档没有直接给一句话答案，但通过各章的 Connectivity 小节可以推出来——看 LMU 和 DAM 的访问路径依赖哪些系统控制配置，依赖方要后配。实际工程里我一般按“时钟和电源先稳、系统控制再配、局部内存最后初始化”的顺序走，因为内存初始化本身依赖时钟稳定。

第 9 章 SCU 里有个值得单独提的点：9.1.1 LBIST considerations for TC37x，下面还细分了 9.1.1.1 TC37x AA。LBIST 是逻辑内建自测试，涉及启动阶段的自检配置。如果你的项目对启动自检有要求，这一节必须细读，因为 LBIST 的配置会影响启动时间和自检覆盖范围，配错了要么启动变慢，要么自检没跑全。9.3.1 还讲了 SCU 到 FPI/BPI 总线的连接，这又回到第 2 章的总线结构，前后是呼应的。

5. 避坑与排查：这份补充手册最容易读错的五个地方

5.1 现象：按家族手册配的寄存器地址访问异常 → 原因：TC37x 有专属寄存器集 → 解决：以补充文档 Specific Register Set 为准

这是最高频的坑。家族手册覆盖面广，但 TC37x 的某些 IP 配置和寄存器集是型号专属的，补充文档每一章的 TC37x Specific Register Set 就是干这个的。现象是代码在别的 AURIX 型号上能跑，换到 TC37x 上访问寄存器就异常或者读到全零。原因是地址偏移或寄存器定义不同。解决办法很直接：所有寄存器地址和位域定义，逐项对照补充文档对应章节，不要跨型号复用。我一般会在代码里给每个寄存器加一行注释，标明出自手册哪一章哪一节，后面排查时能快速回溯。

5.2 现象：擦写 Flash 偶发失败 → 原因：时序参数用了经验值 → 解决：从第 6 章寄存器描述逐项抄时序约束

Flash 擦写偶发失败，重启又好了，这种玄学问题多半是时序参数不对。经验值在不同批次、不同温度下可能刚好卡在边界。手册第 6 章 DMU 和 NVM 的寄存器描述里给了明确的超时和间隔要求，必须逐项抄进配置，不能拍脑袋。解决后建议加一个失败计数和状态记录，下次再出问题能直接看到是超时还是状态位异常。

5.3 现象：自检流程看似通过实则没跑全 → 原因：没对照 Checker 退出信息 → 解决：按 3.1 节确认 ALL CHECKS PASSED 状态

自检代码返回成功不代表自检真的跑完了全部检查。第 3.1 节明确给了全部检查通过时的退出信息，要拿实际读到的值和它比对。现象是系统能启动但某些功能时好时坏，原因可能是自检阶段漏检。解决办法是在启动早期读取退出信息并做严格比对，不通过就停在安全状态，别带着隐患往下跑。

5.4 现象：外设访问吞吐上不去 → 原因：高频外设挂错总线或访问策略不对 → 解决：查第 4 章 Connectivity 确认挂载总线

外设吞吐不达标，先别优化代码，去第 4 章 On-Chip System Connectivity 查这个外设挂在 SRI 还是 SPB 上。挂在 SPB 上的外设做高频批量访问本身就不合适，这是架构层面的限制。确认挂载关系后，再决定是改访问策略还是调整外设分配。4.5.1 的 Domain 0 Interconnection Matrix 是查这个的入口。

5.5 现象：换手册版本后配置对不上 → 原因：忽略了各章 Revision History → 解决：升级前先比对 Revision History 的变更项

这份文档是 V1.6.0，2020 年 8 月版。几乎每一章末尾都有 Revision History，记录了这一章的变更。如果你从旧版本升级过来，或者团队里有人用旧版手册，配置对不上时先翻对应章节的 Revision History，看是不是寄存器定义或参数变了。这个习惯能省掉大量“明明按文档写的却不对”的排查时间。

6. 进阶用法：把这份手册变成团队可检索的配置基线

单看这份文档，价值在于查；用好了，价值在于把它变成团队的配置基线。我的做法是分三步走。第一步，按章节建索引：把第 2 章的内存段、第 4 章的总线连接、第 6 章的 NVM 时序、第 9 章的 SCU 配置这几块抽成表格，每行标注“手册章节号 + 参数名 + 当前工程取值 + 最后核对日期”。第二步，把索引和代码里的宏定义绑定：每个关键寄存器宏旁边写上手出处章节号，代码评审时直接对照索引表检查。第三步，版本升级时先跑一遍 Revision History 比对，把变更项标进索引表，再决定哪些配置要改。

下面这张表是我常用的索引表结构，字段不多但够用：

这张表看着朴素，但它是把一份几百页的补充手册压缩成可执行检查项的关键。团队里新人接手时，不用从头翻文档，对着表逐项核对就能把配置基线摸清。还有一个进阶技巧：把第 13 章 Memory Test Unit (MTU) 的 MEMTEST、MEMMAP、MEMSTAT、MEMDONE、MEMFDA 这几个实现小节，和 13.5.1 的 Ganging for SRAM test and initialization 结合起来看，能搭出一套开机内存自检流程，配合前面说的 Checker 自检，启动阶段的可靠性检查就比较完整了。

从那以后我每次拿到一份新的芯片补充手册，第一件事不是从头读，而是先建这张索引表，把内存、总线、时序、系统控制四类参数先落表，再动代码。这个习惯帮我省掉了很多“文档里明明写了却还是配错”的返工。希望帮到你。

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