首页/资讯中心/详情

CC35xx内存子系统实战：SRAM分区、Cache优化与XiP配置详解

CC35xx内存子系统实战：SRAM分区、Cache优化与XiP配置详解
📅 发布时间：2026/7/26 1:38:33

1. 项目概述

在嵌入式无线MCU的开发中，内存子系统的配置与优化往往是决定项目成败的“隐形战场”。它不像外设驱动那样直观，也不像网络协议那样引人注目，但它的效率直接决定了CPU的“喂食”速度，进而影响整个系统的实时性、功耗和稳定性。最近在基于TI CC35xx系列Wi-Fi 6 & BLE MCU开发一款高性能物联网网关时，我深刻体会到了这一点。项目要求设备在维持多路高吞吐量Wi-Fi数据转发的同时，还需处理复杂的蓝牙Mesh网络协议，这对内存带宽和延迟提出了极致挑战。

CC35xx的内存子系统（MEMSS）设计得非常精巧且复杂，它不是一个简单的存储池，而是一个由片上SRAM、多级缓存（Cache）、外部Flash、PSRAM以及专用的DMA控制器和仲裁器构成的完整生态系统。官方技术手册提供了详尽的寄存器描述和框图，但对于如何根据实际应用场景（比如我们的网关）来配置SRAM分区、启用D-Cache加速PSRAM、以及优化XiP（就地执行）性能，却缺乏“接地气”的实战指南。这导致初期我们直接套用SDK默认配置后，在高负载下频繁出现性能瓶颈和偶发的数据一致性问题。

经过数周的调试、性能剖析和寄存器级的“微操”，我终于摸清了CC35xx内存子系统的“脾气”。本文将抛开枯燥的寄存器列表，从一个嵌入式开发者的视角，深入拆解CC35xx MEMSS的核心组件——SRAM（包括ITCM/DTCM/DMEM）、I-Cache、D-Cache、外部Flash、PSRAM以及XiP相关模块（OTFDE, xSPI, µDMA, Arbiter）的工作原理、配置策略和实战技巧。我会结合网关开发中的真实案例，分享如何根据应用需求选择内存模式、如何配置Cache策略以最大化PSRAM访问效率、以及如何规避XiP模式下的常见陷阱。无论你是正在评估CC35xx进行产品设计，还是已经深陷内存性能优化的泥潭，希望这篇来自一线的经验总结能为你提供清晰的路线图和实用的“避坑”指南。

2. 内存子系统整体架构与设计思路

CC35xx的内存子系统设计核心思想是“分层优化，专域专用”。它并非将所有内存视为一个均质的整体，而是根据速度、功耗、容量和用途进行了精细划分，并通过硬件模块协同工作，以应对无线MCU应用中对实时性、大数据处理和低功耗的复合需求。

2.1 核心组件与数据通路解析

从系统框图看，MEMSS是一个以Cortex-M33核心和两个AHB总线（C-AHB, S-AHB）为中心的网络。理解各组件如何接入这个网络，是进行配置和优化的前提。

1. 核心执行与存储单元：

  • Cortex-M33 Core:系统的“大脑”，通过I-Cache获取指令，通过D-Cache和DTCM访问数据。它对延迟最为敏感。
  • ITCM (Instruction Tightly Coupled Memory):指令紧耦合内存。这是离CPU最近、延迟最低的指令存储器。通常用于存放最关键的、要求确定性执行时间的代码段，例如中断服务程序（ISR）、实时操作系统（RTOS）的内核调度器、或Wi-Fi/蓝牙协议栈中的时间关键型函数。CC35xx允许用户在32kB I-Cache和32kB ITCM之间进行权衡配置。
  • I-Cache (Instruction Cache):指令缓存。用于缓存从外部Flash（通过XiP）或PSRAM中取出的指令。当CPU需要执行非ITCM中的代码时，I-Cache能极大减少访问慢速外部存储带来的性能损失。它是提升XiP模式执行效率的关键。
  • DTCM (Data Tightly Coupled Memory):数据紧耦合内存。与ITCM类似，是延迟最低的数据存储器。用于存放频繁访问的全局变量、堆栈、以及实时性要求最高的数据缓冲区。CC35xx的DTCM大小可在128kB/96kB/64kB之间配置，部分容量可让渡给D-Cache。
  • DMEM (Data Memory):通用数据内存。容量较大（256kB或更多，取决于模式），但速度低于DTCM。适合存放较大的数据块、应用层的全局变量池、以及不那么频繁访问的数据。
  • D-Cache (Data Cache):数据缓存。专门用于加速对PSRAM的数据访问。PSRAM虽然容量大，但速度远慢于片上SRAM。D-Cache通过缓存PSRAM中的热点数据，使得CPU访问PSRAM的数据区域能获得接近SRAM的速度体验。

2. 外部存储与接口单元：

  • Flash:非易失性存储，用于存放程序代码、常量数据以及OTA更新镜像。CC35xx支持最高64MB，但其中仅8MB支持XiP（就地执行）。Flash可以通过QSPI或OSPI接口连接，可以是外部独立芯片，也可以是堆叠在封装内的芯片。
  • PSRAM:伪静态RAM，是一种容量大、成本较低的外部易失性内存。主要用于扩展数据存储空间，例如存放网络数据包、音频帧、图像缓冲区等。CC35xx的PSRAM仅支持堆叠封装形式。特别注意：PSRAM中的数据断电即丢失。
  • xSPI Controller:串行外设接口控制器，支持标准SPI、QSPI（4线）和OSPI（8线）模式。它是CPU和D-Cache访问外部Flash/PSRAM的物理通道。其时钟频率（最高80MHz）和模式（SDR/DDR）直接影响外部内存的访问带宽。
  • OTFDE (On-The-Fly Decryption Engine):实时加解密引擎。这是实现安全XiP的核心。它可以在代码从Flash读取到I-Cache的过程中实时解密，保护知识产权。同时，它也管理着内存区域的映射、安全属性（安全/非安全域）和访问权限。

3. 数据搬运与仲裁单元：

  • µDMA (Micro DMA):也称为外部DMA。这是一个专为外部内存（Flash/PSRAM）与内部SRAM之间大数据块搬运而优化的DMA控制器。它拥有两个通道，可以配置为安全或非安全模式。当应用需要将大量数据（如固件升级包、文件系统数据）从Flash加载到SRAM，或将采集的数据从SRAM存入PSRAM时，使用µDMA可以解放CPU，大幅提升系统效率。
  • Host DMA:这是用于外设与内部SRAM之间数据交换的DMA控制器。例如，Wi-Fi模块接收到的网络数据包可以直接通过Host DMA搬运到SRAM中，无需CPU参与。
  • Arbiter (EMA):外部内存仲裁器。当I-Cache（取指）、D-Cache（访问PSRAM数据）和µDMA（数据搬运）同时需要访问外部内存（通过OTFDE）时，仲裁器决定谁先谁后。其优先级固定为：I-Cache (最高) > D-Cache (中) > µDMA (最低)。这个优先级策略至关重要，它保证了CPU取指指令的实时性，避免因数据搬运或缓存填充导致CPU“饿死”。

2.2 设计思路与权衡

理解上述架构后，配置内存子系统的思路就清晰了，本质上是做一系列资源分配的权衡：

  1. 速度 vs 容量：ITCM/DTCM最快但容量小，SRAM次之，PSRAM/Flash容量大但速度慢。需要将最关键的代码和数据放入TCM，次关键的代码通过I-Cache从Flash执行，大数据块放入PSRAM并通过D-Cache加速。
  2. 实时性 vs 灵活性：ITCM提供确定性的低延迟，适合硬实时任务。而使用Cache从Flash执行代码（XiP）更加灵活（无需将代码预先加载到RAM），但会引入因缓存未命中（Cache Miss）导致的不确定性延迟。
  3. 功耗考量：频繁访问外部存储器（尤其是Flash）会消耗更多功耗。合理的Cache配置和DMA使用可以减少CPU活跃时间和总线访问，从而降低整体功耗。
  4. 安全域隔离：利用TrustZone技术，可以将内存区域（如Flash的某个分区）和DMA通道（µDMA）划分为安全和非安全域，保护关键代码和数据。

在我们的网关项目中，最终的配置策略是：将Wi-Fi驱动和蓝牙协议栈的时间关键中断服务程序放入ITCM；将协议栈核心和数据包处理函数通过I-Cache从Flash执行；开辟一块大的DTCM区域作为网络数据包的接收/发送描述符环；利用PSRAM（通过D-Cache）作为多路TCP连接的数据缓冲区；使用µDMA在系统启动时将压缩的配置文件从Flash解压到PSRAM。这套配置经过压力测试，在满负荷下CPU利用率稳定，且未出现因内存访问冲突导致的丢包。

3. 核心内存组件详解与配置实战

理解了整体架构，我们深入到每个核心组件，看看如何具体配置和优化。

3.1 SRAM：紧耦合内存与通用内存的配置艺术

CC35xx的片上SRAM是其性能基石。它并非一块“铁板”，而是被划分为ITCM、DTCM和DMEM，且大小可配置。

3.1.1 内存模式（Memory Mode）选择

这是系统启动时就需要决定的顶层配置，直接影响可用内存的容量和布局。手册中提到了几种模式，但用户主要关注Mode 0 (Baseline)和Mode 5 (No BLE, Extend M33 Data)。

  • Mode 0 (基线模式):提供完整的功能集，是所有无线功能（Wi-Fi 6, BLE）都启用时的标准配置。DMEM为512kB。
  • Mode 5 (无BLE扩展数据模式):当你的应用不需要蓝牙功能时，可以选择此模式。系统会将原本分配给蓝牙协议栈和RF部分的一些专用SRAM释放出来，合并到M33可用的DMEM中，使DMEM增加到576kB。这是一个非常重要的性能提升点，对于纯Wi-Fi设备，务必启用此模式以获取更大的数据内存。

配置方法：内存模式通常通过芯片的启动配置引脚（Boot CFG Pins）或OTP（一次性可编程存储器）中的特定位在复位时确定。具体需要参考芯片的数据手册和启动引导章节。在SDK中，通常会有相应的宏或配置文件来定义此模式。例如，在board.c或链接脚本中，可能会根据预编译宏来分配不同的内存区域。

3.1.2 I-Cache与ITCM的容量权衡

这是第一个关键抉择点。总共64kB的指令侧内存，如何分配？

  • 选项A: 32kB I-Cache + 32kB ITCM
    • 优点：拥有32kB的超低延迟ITCM，可以放置大量关键代码，获得极致的实时性。
    • 缺点：I-Cache只有32kB，对于代码量较大的应用，缓存未命中率可能增高，影响从Flash执行代码的效率。
  • 选项B: 64kB I-Cache + 0kB ITCM
    • 优点：更大的I-Cache能更好地覆盖代码工作集，提升XiP模式下的平均执行速度，尤其适合代码量大且热点分散的应用。
    • 缺点：完全没有ITCM，所有代码都通过Cache执行，最坏情况下的延迟由Cache未命中时间决定，不适合有严格实时性要求的代码段。

如何选择？

  1. 分析你的代码：使用编译器的-ffunction-sections选项，并在链接后使用size命令或map文件，查看各个函数的大小。找出那些被频繁调用或位于关键中断路径上的函数（如wlan_rx_isr,timer_isr等）。
  2. 计算总大小：将这些关键函数的大小累加。如果总和显著小于32kB，那么选项A是理想选择，你可以把所有关键代码塞进ITCM，享受确定性延迟。
  3. 考虑代码增长：为未来预留空间。如果你的关键代码目前接近32kB，或者项目处于早期阶段，选择选项B可能更稳妥，以避免后期因ITCM不足而大规模重构代码。
  4. 实测验证：如果难以抉择，可以进行基准测试。分别用两种配置编译，在典型负载下测量任务最坏情况执行时间（WCET）和系统吞吐量。

在我们的网关项目中，Wi-Fi和蓝牙的底层中断处理、以及网络协议栈的定时器回调函数总计约28kB。我们选择了32kB I-Cache + 32kB ITCM的配置，将这些函数通过链接脚本强制放入ITCM区域。实测表明，在高中断频率下，系统响应依然稳定。

3.1.3 D-Cache与DTCM的容量权衡

这是数据侧的权衡。总共128kB的紧耦合数据内存，如何分配？

  • 选项1: 128kB DTCM + 0kB D-Cache
  • 选项2: 96kB DTCM + 32kB D-Cache
  • 选项3: 64kB DTCM + 64kB D-Cache

决策逻辑：

  • 如果你不使用PSRAM，或者PSRAM仅用于存储很少访问的冷数据：选择选项1。将全部128kB用作DTCM，为应用程序提供最大的超低延迟数据空间。
  • 如果你大量使用PSRAM作为数据缓冲区（如图像、音频、网络包），并且访问模式存在局部性：选择选项2或3。D-Cache能显著加速对PSRAM的访问。你需要评估热点数据的大小。例如，我们的网关需要同时处理多个TCP流的滑动窗口数据，热点数据约在40-50kB左右波动，因此选择了选项2 (96kB DTCM + 32kB D-Cache)。将最活跃的20-30kB数据指针和元数据放在DTCM，而实际的数据包内容通过D-Cache在PSRAM中高效访问。
  • 配置方法：与I-Cache/ITCM配置类似，通常通过启动配置或SDK的特定API进行设置。注意，D-Cache是专门用于PSRAM的，对Flash访问无效。

3.2 D-Cache：PSRAM性能加速器的深度配置

D-Cache是解锁PSRAM高性能访问的钥匙。其配置远不止分配大小那么简单。

3.2.1 Cacheable与Non-Cacheable区域划分

D-Cache允许你将PSRAM的地址空间划分为可缓存（Cacheable）和不可缓存（Non-Cacheable）区域，粒度是4KB。这是一个非常强大的功能。

  • 可缓存区域 (Cacheable):适用于访问频繁、且数据一致性由软件管理（或通过Cache维护操作管理）的区域。例如，应用程序的堆空间、频繁读写的缓冲区。
  • 不可缓存区域 (Non-Cacheable):适用于以下场景：
    1. DMA缓冲区：当µDMA或Host DMA直接读写PSRAM的某个区域时，该区域必须设置为Non-Cacheable。因为DMA操作不经过Cache，如果Cache中存在该地址的旧数据副本，会导致数据不一致（Cache Coherency Problem）。这是最常见的坑！
    2. 内存映射寄存器：如果PSRAM的某个区域被映射为某个外部设备的寄存器窗口（虽然不常见），必须设为Non-Cacheable。
    3. 严格顺序访问：某些对访问顺序有严格要求的场景。

配置实战：在SDK中，通常通过内存保护单元（MPU）或特定的D-Cache配置寄存器来设置这些属性。你需要定义一个段（Section），在链接脚本（.cmd文件）中将其分配到PSRAM的特定地址范围，并为其设置Non-Cacheable属性。例如，为µDMA创建一个专用的数据缓冲区段。

3.2.2 缓存策略：Write-Back与Write-Allocate

D-Cache对可缓存区域采用写回（Write-Back, WB）和写分配（Write-Allocate, WA）策略。理解这对软件行为的影响至关重要。

  • 写命中（Write Hit）：CPU写数据到已缓存的地址。数据只更新Cache中的行，并标记该行为“脏”（Dirty），不会立即写回PSRAM。直到该缓存行需要被替换（为新数据腾出空间）时，脏数据才会被写回PSRAM。
    • 影响：提升了写性能，但带来了数据延迟写入PSRAM的风险。如果此时系统崩溃或断电，Cache中未写回的数据将丢失。
  • 写未命中（Write Miss）：CPU写数据到一个未缓存的地址。Cache会执行“写分配”：先将目标地址所在的整个缓存行（比如32字节）从PSRAM读入Cache，然后更新Cache中对应的部分，并标记为脏。同样不会立即写回PSRAM。
  • 读未命中（Read Miss）：CPU读取一个未缓存的地址。Cache会执行“读分配”：将整个缓存行从PSRAM读入Cache。

软件必须处理的维护操作：由于Write-Back策略，软件在特定时刻必须主动维护Cache一致性。

  1. 刷新（Flush）：将Cache中所有“脏”的数据强制写回PSRAM。在数据需要被DMA读取、或系统即将进入低功耗模式前，必须对相应的Cacheable区域执行Flush操作。CC35xx的D-Cache提供了FLUSH控制位（CTRL1.FLUSH）来触发此操作。
  2. 无效化（Invalidate）：清空Cache中的指定行，标记其为空。在DMA或其他主设备（如另一个CPU核，如果存在）向PSRAM写入新数据后，CPU在读取该数据前，必须对相应的Cacheable区域执行Invalidate操作，否则CPU读到的将是Cache中的旧数据。CC35xx的D-Cache提供了INVALIDATE控制位（CTRL1.INVALIDATE）。

避坑指南：

  • DMA数据搬运前后的必须操作：
    • DMA从PSRAM读取数据前：确保CPU对源地址区域的写操作已经完成，并执行Cache Flush。
    • DMA向PSRAM写入数据后：在CPU读取目标地址数据前，执行Cache Invalidate。
  • 使用SDK提供的API：TI的SDK通常会封装CacheP_flush和CacheP_invalidate等函数。务必在DMA传输前后正确调用它们。
  • 监控状态：可以通过STATUS1寄存器查询Flush和Invalidate操作是否完成，以及是否失败。

3.3 Flash与XiP：就地执行与安全启动

XiP允许CPU直接从外部Flash执行代码，无需先将代码拷贝到RAM，节省了宝贵的SRAM空间。

3.3.1 OTFDE：安全XiP的守护者

OTFDE模块是XiP的核心，它提供了两个关键功能：

  1. 地址映射与区域划分：它将物理的Flash地址空间映射到CPU的存储器地址空间，并可以划分为多个独立的逻辑区域（至少4个），每个区域可以独立配置安全属性（安全/非安全）和加密属性。
  2. 实时加解密（AES-128-CTR）：可以对指定区域的代码和数据进行实时加解密。这是实现安全启动、保护固件IP的核心。加密的镜像被烧录到Flash，OTFDE在取指时实时解密，对CPU透明。

配置要点：

  • 密钥与IV管理：每个加密区域需要独立的AES密钥和初始化向量（IV）。这些密钥通常在生产时通过安全方式注入芯片（如使用TI的密钥管理工具）。
  • 区域粒度：最小4KB。你需要合理规划Flash布局，例如：Bootloader区（安全，加密）、主应用区（安全，加密）、非安全应用区（非安全，明文）、NV数据区（安全，加密）等。
  • 写保护：OTFDE支持对区域进行写保护，防止运行时被恶意篡改。

3.3.2 xSPI控制器配置

xSPI控制器的配置直接影响Flash访问速度。

  • 模式选择：QSPI (4线) 还是 OSPI (8线)。OSPI在相同时钟下能提供双倍的数据带宽。
  • 时钟频率：最高80MHz。需确保Flash芯片支持该频率。
  • 时序模式：SDR (单倍数据率) 或 DDR (双倍数据率)。DDR能进一步提升吞吐量。
  • DQS信号：在高速DDR模式下，使用DQS（数据选通）信号可以提高数据采样的稳定性。

配置建议：参考Flash芯片的数据手册，选择芯片支持的最高性能模式。在CC35xx的SDK中，通常有一个flash.c或ospi.c的驱动文件，其中包含一个设备配置结构体，你需要根据实际连接的Flash型号填写正确的命令集、地址模式、 dummy cycles和上述的时序参数。

3.4 外部内存拓扑与硬件连接

CC35xx支持多种Flash和PSRAM的组合方式，硬件设计时必须明确。

拓扑选择与电压考量：这是硬件工程师和嵌入式软件工程师必须对齐的关键信息。根据手册中的表格，有几点需要特别注意：

  1. 电压一致性是关键：

    • 当使用堆叠（Stacked）的PSRAM时（拓扑4和5），VDDSF（Flash电源）和VIO2（部分I/O电源）必须连接到同一个1.8V电源。因为堆叠的PSRAM和Flash都是1.8V器件。
    • 当仅使用外部QSPI Flash（拓扑1）时，VDDSF可以是1.8V或3.3V，VIO2可以独立配置。
    • 当使用外部OSPI Flash（拓扑2）时，D[7:4]和DQS引脚由VIO2供电，因此VIO2必须与VDDSF电压相同。

  2. 拓扑决定可用资源：

    • 拓扑3（仅堆叠Flash）：XiP引脚在内部连接，外部引脚可用作其他功能（如GPIO）。这为引脚紧张的设计提供了灵活性。
    • 拓扑4/5（外部Flash+堆叠PSRAM）：这是兼顾大容量代码存储（外部Flash）和大容量数据内存（堆叠PSRAM）的常见选择。注意，此时Flash和PSRAM共享xSPI总线，需要通过片选（CS）信号切换访问。

硬件设计检查清单：

  • 确认选择的CC35xx器件型号是否支持你想要的拓扑（例如，是否包含堆叠PSRAM）。
  • 根据拓扑图，正确连接VDDSF和VIO2的电源。
  • 为xSPI信号线（CLK, DQ[7:0], CS等）做好PCB布局的阻抗控制和长度匹配，尤其是在80MHz DDR模式下。

4. 高级主题：µDMA与仲裁器的协同优化

当系统需要高效地在内部SRAM和外部内存之间搬运数据时，µDMA和仲裁器（EMA）的作用就凸显出来了。

4.1 µDMA：高效的数据搬运工

µDMA只有两个通道，但设计精巧。

  • 通道配置：两个通道可以独立配置为安全或非安全通道，必须与它们所要访问的内存区域的安全属性匹配。
  • 连续传输模式：支持“连续服务”（Continuation of service），即一个通道传输完成后，另一个通道可以自动开始。这可以用来设置一个简单的乒乓缓冲区（Ping-Pong Buffer）传输。
  • 专用场景：µDMA专为内存到内存的传输优化，特别是涉及外部Flash/PSRAM的场景。例如：
    • 系统启动时，将压缩的固件或文件系统从Flash解压到PSRAM。
    • 将采集到的大批量传感器数据从DTCM搬运到PSRAM进行暂存。
    • 将PSRAM中处理完毕的网络数据通过µDMA搬回内部SRAM，再由Host DMA发送给Wi-Fi模块。

使用技巧：

  • 对齐与突发：µDMA传输宽度固定为32位。确保源地址和目标地址至少32位对齐（4字节对齐）以获得最佳性能。
  • 与Cache协同：如前所述，如果µDMA的源或目标地址位于PSRAM的Cacheable区域，必须在传输前后进行正确的Cache维护操作（Flush/Invalidate）。
  • 中断使用：可以为每个通道配置传输完成中断，以便在中断服务程序中启动下一轮传输或处理数据。

4.2 仲裁器（EMA）：交通指挥官

仲裁器的优先级策略（I-Cache > D-Cache > µDMA）是系统稳定的重要保障。理解其影响有助于诊断性能问题。

  • 场景分析：假设系统正在通过µDMA从Flash向PSRAM搬运一个巨大的固件更新包（低优先级）。同时，应用程序正在密集地通过D-Cache访问PSRAM中的数据进行计算（中优先级）。此时，如果发生I-Cache未命中，CPU需要从Flash取指（高优先级）。
  • 结果：仲裁器会暂停µDMA的传输，甚至可能暂停D-Cache对PSRAM的访问，优先服务I-Cache的取指请求。这保证了CPU不会因为等待指令而停滞，但可能会降低µDMA的平均吞吐量。
  • 优化思路：
    1. 关键代码ITCM化：将最时间关键的代码放入ITCM，减少I-Cache未命中，从而降低高优先级请求的频率，给µDMA和D-Cache更多带宽。
    2. 错峰传输：将大的µDMA传输任务安排在系统相对空闲的时段，或者将其分解为多个小任务分批执行。
    3. 监控性能计数器：I-Cache和D-Cache模块都提供了HIT_COUNTER和MISS_COUNTER。通过监控这些计数器，可以量化Cache的效率，并判断是否因仲裁导致D-Cache未命中率异常升高。

5. 实战配置流程与常见问题排查

5.1 基于SDK的典型配置流程

以下是一个基于TI SimpleLink SDK的典型内存子系统初始化与配置流程概述，具体函数名可能因SDK版本而异：

  1. 系统初始化：调用Board_init()或类似函数，初始化MCU时钟、引脚复用等。此时会根据硬件设计（如启动引脚）确定基本的内存模式（Memory Mode）。
  2. Flash/OSPI驱动初始化：调用OSPI_init()或Flash_init()，根据板级配置（board.c中定义的OSPI_Handle和OSPI_Config）初始化xSPI控制器，设置正确的时钟、模式和时序参数。这一步建立了CPU访问外部Flash的物理通道。
  3. 内存保护单元（MPU）配置：如果使用TrustZone，需要配置MPU来定义不同内存区域（如ITCM, DTCM, Flash安全区, PSRAM Cacheable区）的安全属性和访问权限。SDK可能提供MPU_config()之类的函数。
  4. Cache配置：
    • I-Cache/ITCM划分：通常在链接脚本（.cmd文件）中通过定义ITCM段来实现。编译器/链接器会将指定函数放入该段。同时，需要在启动代码或系统初始化早期，通过配置相应的寄存器（可能由SDK的CacheP_enable()内部处理）来设置I-Cache/ITCM的大小分配。
    • D-Cache使能与区域配置：调用CacheP_enable(CacheP_TYPE_D)使能D-Cache。通过MPU或特定API（如CacheP_setRegion()）配置PSRAM中哪些地址范围是Cacheable的。
  5. OTFDE配置（如果使用安全XiP）：在生产环境中，通过TI的安全工具将密钥注入芯片。在代码中，需要调用OTFDE驱动API来配置各个逻辑区域的起始地址、大小、加密使能、密钥索引等。这通常在启动加载器（Bootloader）或早期安全服务中完成。
  6. µDMA初始化：调用UDMA_init()初始化µDMA控制器，并配置通道控制结构体（UDMA_ControlTable）。

5.2 常见问题与排查技巧实录

以下是我在项目中实际遇到过的典型问题及解决方法：

问题1：系统运行不稳定，偶尔出现指令取指错误或数据访问错误。

  • 排查思路：
    1. 检查电源完整性：尤其是给VDDSF和VIO2供电的1.8V/3.3V电源纹波是否在芯片要求范围内。高速xSPI接口对电源噪声非常敏感。使用示波器测量。
    2. 检查时钟配置：确认xSPI控制器时钟（如80MHz）是否准确，是否存在过冲或抖动。
    3. 检查信号完整性：检查xSPI的CLK和DQ线是否有过冲、振铃或串扰。确保PCB走线阻抗匹配，长度大致相等。
    4. 降低xSPI频率：尝试将xSPI时钟从80MHz DDR降低到40MHz SDR，看问题是否消失。如果消失，则是硬件设计或PCB布局问题。
    5. 检查Flash/PSRAM型号兼容性：确认使用的Flash/PSRAM芯片完全支持CC35xx xSPI控制器支持的所有命令和时序模式。仔细核对数据手册中的Dummy Cycles等参数。

问题2：使用µDMA从PSRAM搬运数据到SRAM，发现SRAM中的数据是旧的（不一致）。

  • 根本原因：Cache一致性问题。CPU之前写过PSRAM源地址的数据，但数据只停留在D-Cache中（标记为Dirty），未写回PSRAM。µDMA直接从PSRAM读取，得到的是旧数据。
  • 解决方案：在启动µDMA传输之前，对PSRAM源地址所在的Cacheable区域执行CacheP_flush()操作。

问题3：CPU读取了经由µDMA更新后的PSRAM数据，但读到的还是旧值。

  • 根本原因：同样是Cache一致性问题。µDMA更新了PSRAM，但CPU的D-Cache中仍然缓存着该地址的旧数据。
  • 解决方案：在µDMA传输完成之后，CPU读取数据之前，对PSRAM目标地址所在的Cacheable区域执行CacheP_invalidate()操作。

问题4：使能D-Cache后，系统性能反而下降，或出现诡异的数据错误。

  • 排查思路：
    1. 检查Cacheable区域配置：确认是否为DMA缓冲区等本应设为Non-Cacheable的区域错误地配置成了Cacheable。
    2. 检查Cache维护操作：仔细审查所有涉及PSRAM的DMA操作前后，是否遗漏了Flush或Invalidate操作。
    3. 检查多任务/中断环境：如果多个任务或中断例程会访问同一块PSRAM Cacheable区域，需要考虑软件互斥（如使用互斥锁）来保护，或者在任务切换时进行必要的Cache维护。更简单的做法是，将需要共享的缓冲区放在Non-Cacheable区域，以一致性换取性能（但访问变慢）。
    4. 使用Cache诊断功能：读取D-Cache的READ_COUNTER和WRITE_COUNTER，计算命中率。如果命中率极低（例如<50%），说明你的数据访问模式非常随机，没有局部性，此时使用Cache可能弊大于利。考虑调整数据结构或访问模式。

问题5：XiP模式下代码执行速度慢，系统响应迟钝。

  • 排查思路：
    1. 检查I-Cache命中率：读取I-Cache的HIT_COUNTER和MISS_COUNTER。如果未命中率很高，说明I-Cache大小可能不足，或者代码过于分散。
    2. 优化代码布局：使用编译器的-freorder-functions和-freorder-blocks-and-partition等优化选项，帮助链接器将频繁调用的函数（热点代码）聚集在一起，提高I-Cache的局部性。
    3. 考虑使用ITCM：将最关键的循环或中断处理函数放入ITCM。
    4. 检查xSPI配置：确认Flash是否运行在支持的最高性能模式（如OSPI DDR 80MHz）。检查Flash访问时序参数是否正确。

问题6：如何监控和调试内存子系统的性能？

  • 利用性能计数器：I-Cache和D-Cache的命中/未命中计数器是宝贵的调试信息。可以在代码的关键节点读取并打印这些计数器，分析Cache效率。
  • 使用调试器观察：在IDE（如CCS）中，可以查看内存映射，确认链接脚本是否正确地将代码和数据分配到了预期的区域（ITCM, DTCM, PSRAM等）。
  • 基准测试：编写简单的微基准测试程序，例如，循环访问PSRAM中的一个大数组，分别测试Cache使能和关闭时的速度差异，量化D-Cache带来的收益。
  • 总线分析仪：如果有条件，使用总线分析仪抓取AHB总线或xSPI接口上的事务，可以直观地看到仲裁情况、访问延迟和带宽利用率。