1. 项目概述在嵌入式无线MCU的开发中内存配置往往是最容易被忽视却又对系统性能、功耗和稳定性影响最深远的环节。很多工程师拿到一款像TI CC35xx这样的高性能无线MCU第一反应是去研究其Wi-Fi 6和蓝牙低功耗的射频性能却容易忽略其复杂而精妙的内存子系统MEMSS。实际上对于需要处理复杂网络协议栈、进行实时数据处理或运行轻量级操作系统的应用来说不合理的内存配置轻则导致性能瓶颈重则引发难以调试的随机崩溃。CC35xx系列提供了高度灵活的内存架构包括可动态划分的片上SRAM、用于加速的外部存储器Cache、以及支持片上执行XiP和实时加解密OTFDE的外部Flash/PSRAM接口。理解这套子系统意味着你能从芯片层面榨取每一分性能并构建出更稳定、更省电的产品。本文将结合手册内容与实际开发经验为你拆解CC35xx内存子系统的每一个核心模块并提供从原理到配置再到避坑的完整指南。2. 内存子系统整体架构与设计思路CC35xx的内存子系统设计遵循了经典的存储层次结构理念旨在平衡速度、容量、功耗和成本。其核心思路是利用高速、低延迟的片上SRAM作为“工作台”而将大容量的代码和数据存放在外部串行存储器中并通过缓存Cache和直接内存访问DMA等机制来弥合两者之间的速度鸿沟。2.1 核心组件与访问路径从系统框图来看CC35xx的MEMSS是一个以Cortex-M33核心为中心连接多种存储介质和总线主设备的复杂网络。我们可以将其主要组件和访问关系梳理如下主控核心M33 MCU系统的“大脑”负责指令取指和数据读写。它通过系统总线如C-AHB, S-AHB访问所有内存。片上SRAM这是性能的基石。CC35xx提供了高达1024KB的片上SRAM并在所有低功耗模式除关机模式外下保持数据。它被进一步细分为ITCM (Instruction Tightly Coupled Memory)指令紧耦合内存。用于存放对延迟极度敏感的关键代码如中断服务程序、实时控制循环。CPU可以无等待周期地访问ITCM。DTCM (Data Tightly Coupled Memory)数据紧耦合内存。用于存放需要被频繁、快速访问的关键数据如协议栈的控制块、实时传感器数据缓冲区。DMEM (Data Memory)通用数据内存。用于存放全局变量、堆栈、以及不那么紧急的数据。I-Cache (Instruction Cache)指令缓存。用于缓存从外部Flash或PSRAM中取出的指令减少访问延迟。D-Cache (Data Cache)数据缓存。专门用于加速对PSRAM中数据的访问。外部存储器串行Flash容量可达64MB其中8MB支持XiP执行用于存储程序代码、常量以及需要掉电保存的数据如网络配置、OTA镜像。它可以是外置的也可以是堆叠在封装内的。串行PSRAM容量可达64MB仅支持堆叠封装。这是一种易失性内存主要用于扩展数据存储空间例如存放大的音频缓冲区、图形帧缓冲区或协议栈的临时数据。特别注意PSRAM不能用于XiP执行代码。访问代理与仲裁µDMA (外部DMA)这是一个专用于在外部存储器Flash/PSRAM和片上SRAM之间搬运数据的DMA控制器。它有两个通道可以配置为安全或非安全能显著减轻CPU在数据搬运上的负担例如在OTA升级时从Flash读取新固件到SRAM。主机DMA用于在外设如ADC, SPI和片上SRAM之间传输数据。外部内存仲裁器 (EMA)当I-Cache取指、D-Cache访问PSRAM数据和µDMA数据搬运同时需要访问外部存储器时由EMA来仲裁访问权限。其优先级顺序为I-Cache (最高) D-Cache (中) µDMA (最低)。这确保了代码执行的实时性优先于数据访问。2.2 内存模式启动时的关键抉择CC35xx在启动时Boot允许开发者选择不同的“内存模式”这决定了片上SRAM资源在I-Cache/ITCM和D-Cache/DTCM之间的分配比例。这是一个一次性、不可运行时更改的配置直接影响后续所有软件的性能特征。手册中提到了几种模式其中对用户开放的主要是Mode 0 (基线模式)和Mode 5 (无BLE扩展M33数据模式)。我们以最常用的Mode 0为例其配置灵活性体现在两个独立的决策上决策一指令侧分配 (I-Cache vs. ITCM)你有64KB的指令侧高速存储资源可以将其全部用作I-Cache也可以拆分成两部分。选项A: 64KB I-Cache 0KB ITCM这是“性能优先”选项。大的I-Cache能更好地缓存外部Flash中的代码尤其适合代码量大、分支多的复杂应用能有效提升XiP执行的效率。选项B: 32KB I-Cache 32KB ITCM这是“确定性优先”选项。将32KB关键代码如网络协议栈的核心部分、实时中断处理锁定在ITCM中确保其执行时间绝对可预测不受缓存命中/未命中的影响。剩余的32KB I-Cache用于缓存其他代码。如何选择如果你的应用有严格的实时性要求例如电机控制、精确时序的无线通信或者有一部分代码的执行频率极高那么分配一部分ITCM是明智的。否则全部用作I-Cache通常能获得更好的整体性能。决策二数据侧分配 (D-Cache vs. DTCM)你有128KB的数据侧紧耦合存储资源可以在DTCM和D-Cache之间分配。选项A: 128KB DTCM 0KB D-Cache所有数据都放在高速DTCM中访问最快但容量有限。适合数据量不大但对访问速度要求极高的场景。选项B: 96KB DTCM 32KB D-Cache折中方案。将最热的数据放在DTCM同时用D-Cache来加速对PSRAM中较大数据集的访问。选项C: 64KB DTCM 64KB D-Cache偏向于处理PSRAM中大容量数据的场景。用较大的D-Cache来提升对PSRAM的访问效率牺牲一部分DTCM的绝对速度。如何选择这取决于你的数据访问模式。如果你的应用有大量数据需要存放在PSRAM中如图像处理、音频缓冲并且访问具有局部性反复访问同一块数据那么配置较大的D-Cache收益明显。如果数据量小但访问随机且频繁则应倾向于更大的DTCM。实操心得模式选择的权衡在实际项目中我通常采用“性能剖析迭代调整”的方法。首先基于应用特点做一个初步选择例如物联网网关代码量大选64KB I-Cache需要处理摄像头数据选64KB D-Cache。然后在SDK提供的内存链接脚本.cmd文件中精确定义哪些函数/数据段放到ITCM/DTCM。最后利用芯片的性能计数器如Cache命中/未命中计数器来验证配置的有效性必要时进行调整。记住没有“最好”的模式只有“最适合”你当前应用的模式。3. 核心组件深度解析与配置要点3.1 SRAM分区与链接脚本配置理解了内存模式后下一步就是通过链接器脚本Linker Script将你的代码和数据精确地放置到合适的内存区域。这是将硬件配置转化为软件性能的关键一步。ITCM/DTCM的链接脚本实践以TI的CCS或IAR开发环境为例你需要修改链接器命令文件.cmd。以下是一个简化的示例展示了如何将特定段分配到ITCM和DTCM/* 内存区域定义 (对应硬件地址) */ MEMORY { /* 程序存储器 */ FLASH (RX) : origin 0x00000000, length 0x00800000 /* 8MB 可执行Flash */ ITCM (RX) : origin 0x00000000, length 0x00008000 /* 32KB ITCM注意地址可能与FLASH重叠由总线区分 */ /* 数据存储器 */ SRAM (RW) : origin 0x20000000, length 0x00040000 /* 256KB 通用DMEM */ DTCM (RW) : origin 0x20040000, length 0x00020000 /* 128KB DTCM */ /* 外部PSRAM (非可执行) */ PSRAM (RW) : origin 0x80000000, length 0x00400000 /* 4MB PSRAM */ } /* 段放置 */ SECTIONS { /* 将中断向量表和最关键的启动代码放入ITCM确保最快响应 */ .intvecs : ITCM .text:fastcode : { *(.text:fastcode) } ITCM /* 使用section属性标记的关键函数 */ /* 主程序代码放在Flash中通过I-Cache加速 */ .text : FLASH /* 将频繁访问的全局变量、协议栈控制块放入DTCM */ .data:critical : { *(.data:critical) } DTCM .bss:critical : { *(.bss:critical) } DTCM /* 堆栈通常也放在DTCM以获得确定性的访问速度 */ .stack : DTCM /* 普通全局变量和堆放在通用SRAM */ .data : SRAM .bss : SRAM /* 大块数据如音频缓冲区放入PSRAM */ .psram_data : PSRAM }在C代码中你可以使用GCC/ARMCC的section属性来将特定函数或变量分配到自定义段// 将关键函数放入ITCM __attribute__((section(.text:fastcode))) void critical_isr_handler(void) { // ... } // 将高频访问变量放入DTCM __attribute__((section(.data:critical))) uint32_t protocol_state;3.2 D-CachePSRAM的性能加速器D-Cache是CC35xx针对PSRAM访问优化的核心部件。它不像通用CPU的Cache那样透明需要开发者进行显式的区域管理和一致性维护。3.2.1 可缓存区域配置D-Cache最大支持8MB的可缓存Cacheable区域管理粒度是4KB页。你需要通过配置寄存器DCACHE.CAL和DCACHE.CAH来定义PSRAM中哪一段地址范围是Cacheable的。Cacheable区域对此区域的读写会经过D-Cache。如果数据在Cache中Hit则直接高速访问如果不在Miss则会从PSRAM读取一整行Line数据到Cache中Read Allocate。写操作采用回写Write Back策略即先只更新Cache并标记为“脏”Dirty直到该Cache行被替换时才写回PSRAM。Non-Cacheable区域对此区域的访问将绕过Cache直接访问PSRAM。适用于那些只写一次或很少访问或者需要被其他主设备如DMA直接访问的数据以避免Cache一致性问题。配置示例假设你的PSRAM地址从0x8000_0000开始你希望将前2MB0x8000_0000到0x801F_FFFF配置为Cacheable用于存放需要频繁计算的中频数据而后面的部分作为Non-Cacheable用于存放原始采集数据或DMA缓冲区。// 设置Cacheable区域低地址 (按4KB对齐) HWREG(DCACHE_BASE DCACHE_O_CAL) 0x80000000 12; // 取高20位[31:12] // 设置Cacheable区域高地址 HWREG(DCACHE_BASE DCACHE_O_CAH) 0x801FFFFF 12; // 使能D-Cache HWREG(DCACHE_BASE DCACHE_O_CTRL) | DCACHE_CTRL_CENABLE;3.2.2 Cache一致性维护这是使用D-Cache时最容易出错的地方。由于Cache的存在PSRAM中的“真实”数据可能落后于Cache中的“副本”。在以下情况你必须手动维护一致性DMA数据传输当µDMA或主机DMA直接向PSRAM的Cacheable区域写入数据时这些新数据不会自动反映到D-Cache中导致CPU读到的还是旧数据。解决方案是在DMA传输完成后无效化Invalidate对应地址范围的Cache行。CPU修改共享数据如果CPU修改了Cacheable区域的数据这些修改可能还停留在Cache里脏数据。如果此时其他主设备如另一个CPU核或DMA需要读取PSRAM中的最新数据它们读到的将是旧值。解决方案是在CPU写操作后如果需要立即可见则进行写回Flush操作或者在其他主设备读取前由CPU执行Flush。CC35xx的D-Cache提供了相应的控制寄存器Flush (刷新)将Cache中所有被标记为“脏”Dirty的数据行写回到PSRAM然后清除脏标志。DCACHE.CTRL1.FLUSH位。Invalidate (无效化)直接丢弃Cache中指定区域的数据行下次访问时将重新从PSRAM加载。DCACHE.CTRL1.INVALIDATE位。通常在使能D-Cache前或DMA向Cacheable区域写入数据后需要对相应区域进行Invalidate。注意事项Cache操作的成本Flush和Invalidate是批量操作可能会消耗数百甚至上千个时钟周期阻塞CPU。因此应避免在频繁执行的代码路径或实时中断中进行全局的Cache维护。最佳实践是精细化管理只为真正需要维护的、较小的内存范围如一个DMA缓冲区执行Cache操作。异步处理在系统空闲或低优先级任务中执行全局Cache维护。利用非缓存区域对于频繁被DMA访问的共享数据区直接将其定义为Non-Cacheable虽然牺牲了速度但彻底避免了一致性问题简化了软件设计。3.3 外部存储器接口xSPI与拓扑选择CC35xx通过xSPI控制器连接外部Flash和PSRAM。xSPI支持多种工作模式直接影响访问带宽和引脚占用。3.3.1 工作模式传统SPI (1-bit)速度最慢引脚最少CLK, CS, MOSI, MISO。QSPI (Quad SPI, 4-bit)数据线增至4条在相同时钟频率下理论带宽是SPI的4倍。这是最常用的平衡模式。OSPI (Octal SPI, 8-bit)数据线增至8条带宽最大但需要占用更多MCU引脚D[7:0], DQS等。3.3.2 拓扑结构与电压配置这是硬件设计时必须仔细核对的部分。手册中列出了5种拓扑选择取决于你的Flash/PSRAM是外置还是堆叠以及是QSPI还是OSPI。拓扑编号Flash类型PSRAM类型XiP模式VDDSF (Flash电源)VIO2 (PSRAM CS等)关键约束1外置 QSPI Flash无外部 QSPI1.8V 或 3.3V独立 (1.8V/3.3V)最灵活电压可独立选择。2外置 OSPI Flash无外部 OSPI1.8V 或 3.3V必须与VDDSF相同使用OSPI时高4位数据线(D[7:4])和DQS由VIO2供电故电压需一致。3堆叠QSPI Flash无堆叠 QSPI必须为1.8V独立 (1.8V/3.3V)堆叠Flash固定为1.8V。XiP引脚内部连接外部引脚可用作GPIO。4外置 QSPI Flash堆叠QSPI PSRAM外部(QSPI) 堆叠(QSPI)必须为1.8V必须为1.8V堆叠PSRAM为1.8V且其片选(CS)信号在VIO2域故VIO2也必须为1.8V。5外置 OSPI Flash堆叠QSPI PSRAM外部(OSPI) 堆叠(QSPI)必须为1.8V必须为1.8V同拓扑4Flash用OSPI模式以获得更高带宽。设计建议追求高性能如果代码体积大需要快速XiP选择拓扑5外置OSPI Flash 堆叠PSRAM能最大化Flash读取带宽。追求成本与引脚优化如果代码量适中且需要额外RAM选择拓扑4外置QSPI Flash 堆叠PSRAM在性能和引脚数间取得平衡。最简单设计如果不需要PSRAM选择拓扑1外置QSPI Flash硬件设计最简单电压选择灵活。重要只要使用堆叠的PSRAMVDDSF和VIO2必须都连接到1.8V电源。这是一个常见的硬件设计陷阱。3.4 XiP、OTFDE与安全执行XiP (eXecute in Place) 允许CPU直接从外部Flash取指执行无需先将代码拷贝到SRAM。这节省了宝贵的SRAM空间但Flash的读取速度较慢因此需要I-Cache来加速。3.4.1 OTFDE实时加解密引擎OTFDE (On-The-Fly Decryption Encryption) 是CC35xx的一个安全增强特性。它可以在代码从Flash读取到I-Cache的过程中或数据在Flash与系统间传输时进行实时的AES-128加解密。应用场景保护知识产权将核心算法代码加密后存储在Flash中防止被轻易读取和反编译。安全启动确保只有经过签名的加密固件才能被正确解密和执行。安全存储对存储在Flash中的敏感数据如Wi-Fi密码、证书进行加密。工作原理OTFDE将外部Flash地址空间划分为多个独立的区域至少4个每个区域可以配置独立的密钥KEY和初始化向量IV。当CPU或DMA访问某个加密区域时OTFDE硬件自动进行解密当写入数据时则自动加密。对于非加密区域可以配置为旁路Bypass模式。配置流程简述在安全环境中如工厂生产时生成并烧录AES密钥和IV到芯片的安全存储区。在软件中通过配置OTFDE寄存器将Flash的特定地址范围映射到某个密钥区域并设置访问权限安全/非安全只读/可写。使能OTFDE。此后对该区域的访问将自动享受加解密服务。3.4.2 使用XiP的注意事项性能考量即使有I-CacheXiP的执行速度也永远比不上从ITCM或SRAM直接执行。对于最关键的实时循环或中断服务程序仍应考虑放入ITCM。功耗考量每次Cache未命中都需要访问外部Flash这会增加功耗。在低功耗应用中需要仔细评估代码布局提高Cache命中率。链接脚本调整启用XiP后链接脚本中.text代码段的目标地址应设置为Flash的地址范围如0x0000_0000开始而不是SRAM地址。4. 寄存器详解与底层驱动实现手册中提供了大量关于ICACHE和DCACHE的寄存器描述。作为开发者我们不需要记忆每一个位域但需要理解关键寄存器的作用以便进行调试和高级优化。这里我们重点看几个最常用的。4.1 Cache控制与状态寄存器ICACHE.CTRL / DCACHE.CTRL控制寄存器的核心是使能位CENABLE和RAM使能位RENABLE。CENABLE1使能Cache控制器。RENABLE此位含义在I-Cache和D-Cache中不同。对于I-CacheRENABLE1表示将一半Cache空间32KB用作RAM即ITCM另一半32KB用作Cache。RENABLE0表示全部64KB用作Cache。此位在CENABLE置1后即被写保护必须在使能Cache前配置好。对于D-Cache逻辑类似用于在DTCM和D-Cache间分配128KB资源。ICACHE.STATUS / DCACHE.STS状态寄存器。最重要的位是OK_TO_GO。在软件配置完Cache设置地址范围、模式等并使其能后需要轮询此位直到它变为1表示Cache内部初始化如Tag RAM初始化完成可以正常操作。Cache地址范围寄存器 (CAL,CAH)定义了Cacheable区域。如前所述需要按4KB对齐即地址的低12位为0。配置时写入的是地址的[31:12]位。4.2 性能监控与调试寄存器这是进行性能分析和优化的宝贵工具。HIT_COUNTER / MISS_COUNTER (ICACHE)和READ_COUNTER / WRITE_COUNTER (DCACHE)这些计数器分别记录了Cache的命中Hit和未命中Miss次数。应用在代码的关键路径前后读取这些计数器可以定量分析Cache配置的有效性。例如优化函数布局或调整Cacheable区域后观察命中率是否提升。注意计数器达到最大值后会停止。软件可以写入0将其清零。CACHE_FSM_STATE (DCACHE)这个寄存器以编码形式显示了D-Cache内部有限状态机FSM的当前状态。状态包括空闲WIDLE、读命中WCREADT、写回PSRAMEVICT等。在调试复杂的Cache一致性问题时观察FSM状态有助于理解Cache正在进行的操作。ADDRESS_LATCH (DCACHE)当D-Cache从OTFDE接收到AHB错误通常是由于访问了未配置或权限错误的加密区域时出错的访问地址会被锁存到这个寄存器中。这对于调试OTFDE配置错误非常有用。4.3 中断与错误处理寄存器IRQSTATUS_RAW / IRQENABLE_SET 等这些寄存器用于管理Cache相关的错误中断例如配置寄存器在锁定后被错误写入LOCK_CFG_WR。在可靠性要求高的系统中可以使能这些中断并在中断服务程序中进行错误记录或系统恢复。一个典型的D-Cache初始化与配置代码片段可能如下所示#include stdint.h #include “hw_memmap.h” #include “hw_types.h” #include “dcache.h” void DCacheConfigAndEnable(uint32_t cacheableBase, uint32_t cacheableSize) { // 1. 确保传入参数4KB对齐 assert((cacheableBase 0xFFF) 0); assert((cacheableSize 0xFFF) 0 cacheableSize 0); // 2. 计算并设置Cacheable区域的高/低地址 (取高20位) uint32_t cal cacheableBase 12; uint32_t cah (cacheableBase cacheableSize - 1) 12; // 3. 在使能前配置地址范围和模式假设选择64KB D-Cache模式 // 注意以下寄存器地址和位域定义需参考具体SDK头文件 HWREG(DCACHE_BASE DCACHE_O_CAL) cal; HWREG(DCACHE_BASE DCACHE_O_CAH) cah; // 配置CTRL寄存器使能Cache并选择64KB D-Cache模式 (RENABLE0) HWREG(DCACHE_BASE DCACHE_O_CTRL) DCACHE_CTRL_CENABLE; // RENABLE默认为0 // 4. 使能后等待Cache初始化完成 while(!(HWREG(DCACHE_BASE DCACHE_O_STS) DCACHE_STS_OK_TO_GO)) { // 可选加入超时机制 } // 5. 可选使能前无效化整个Cache区域以确保数据一致性 HWREG(DCACHE_BASE DCACHE_O_CTRL1) | DCACHE_CTRL1_INVALIDATE; while(HWREG(DCACHE_BASE DCACHE_O_STS1) DCACHE_STS1_INVALIDATE_STATUS) { // 等待无效化完成 } }5. 常见问题、调试技巧与实战心得在实际项目中使用CC35xx的MEMSS时会遇到各种问题。下面是我总结的一些典型场景和解决方法。5.1 问题排查速查表问题现象可能原因排查步骤与解决方案系统随机崩溃或数据错误尤其在DMA操作后。D-Cache一致性问题。DMA直接写入PSRAM的Cacheable区域但CPU的D-Cache中仍是旧数据。1. 检查DMA目标地址是否在DCACHE.CAL/CAH定义的Cacheable区域内。2. 在DMA传输完成中断中对目标缓冲区地址执行CacheInvalidate()。从Flash XiP执行代码时性能远低于预期。I-Cache未命中率过高。代码过于分散或I-Cache太小。1. 使用ICACHE的MISS_COUNTER验证未命中次数。2. 优化链接脚本将热点函数集中放置利用空间局部性。3. 考虑分配一部分ITCM给最关键的循环。使能OTFDE后访问特定Flash区域触发硬件错误。OTFDE区域配置错误或密钥/IV不匹配。1. 检查ADDRESS_LATCH寄存器获取触发错误的访问地址。2. 核对OTFDE区域配置寄存器确保访问地址落在已正确配置密钥和权限的区域。3. 确认使用的密钥和IV与加密固件时使用的完全一致。系统从低功耗模式唤醒后运行异常。SRAM数据丢失或Cache状态错乱。1. 确认唤醒源对应的低功耗模式是否支持SRAM保持Shutdown模式不支持。2. 在进入低功耗模式前如果D-Cache中有脏数据且对应PSRAM会掉电必须执行CacheFlush()。3. 唤醒后在访问Cacheable的PSRAM区域前先执行CacheInvalidate()。配置了D-Cache但访问PSRAM速度没有改善。1. 访问地址不在Cacheable区域。2. 访问模式是随机的没有局部性。3. D-Cache未成功使能。1. 检查DCACHE.CAL/CAH配置和实际访问地址。2. 检查DCACHE.STS.OK_TO_GO位是否为1。3. 优化数据结构与访问模式尽量顺序访问。使用堆叠PSRAM时系统无法启动或访问失败。VDDSF/VIO2电源电压配置错误。1.硬件检查确认使用堆叠PSRAM时VDDSF和VIO2是否都连接到了1.8V电源拓扑4/5。这是最常见的硬件错误。2.软件检查确认SDK中关于堆叠PSRAM的初始化序列已正确执行。5.2 调试技巧与高级优化利用性能计数器进行剖析在开发阶段定期读取HIT_COUNTER和MISS_COUNTER。计算命中率Hit Rate Hits / (Hits Misses)。针对命中率低的代码段分析其访问模式。是循环太大还是指针跳跃访问尝试调整算法或数据布局。Non-Cacheable区域的巧妙使用不要试图将所有PSRAM都设为Cacheable。将DMA缓冲区、频繁被其他主设备访问的共享数据区设置为Non-Cacheable可以彻底避免一致性烦恼虽然损失一点速度但换来了软件的简洁和稳定。链接脚本的精细打磨不要满足于默认的链接脚本。使用__attribute__((section(“xxx”)))将性能关键的函数和数据精确放置。工具链的map文件是你的好朋友仔细研究它确保关键部分确实放在了ITCM/DTCM。低功耗模式下的Cache处理在进入深度睡眠SRAM保持前如果PSRAM也会掉电必须将D-Cache中的脏数据写回Flush。唤醒后由于PSRAM内容可能无效或已改变需要将对应的Cache区域无效化Invalidate。这是一个容易忽略的细节会导致唤醒后数据错误。与RTOS的协同如果使用FreeRTOS等RTOS需要注意任务堆栈的分配。将中断栈和最高优先级任务的栈放在DTCM中可以保证最坏情况下的响应时间。RTOS的堆heap如果用于频繁动态分配放在通用SRAM或PSRAM中可能更合适。5.3 关于内存模式选择的个人体会经过多个项目的实践我形成了一些经验性的选择策略通用物联网节点传感器数据采集无线传输代码量中等实时性要求一般。我会选择Mode 0配置为 64KB I-Cache 0KB ITCM以及 96KB DTCM 32KB D-Cache。将协议栈的发送/接收缓冲区、加密上下文等放入DTCM将采集到的历史数据缓存放入PSRAM并用D-Cache加速。实时性要求高的控制器如电机控制代码量不大但对中断响应时间要求苛刻。我会选择Mode 0配置为 32KB I-Cache 32KB ITCM以及 128KB DTCM 0KB D-Cache。将PWM控制算法、位置环PID计算函数和中断向量表放入ITCM将所有控制变量和实时数据放入DTCM放弃D-Cache以简化设计。富功能网关设备运行轻量级Linux或复杂协议栈代码量巨大需要处理大量网络数据包。我会选择Mode 0配置为 64KB I-Cache 0KB ITCM以及 64KB DTCM 64KB D-Cache。最大化I-Cache来加速大型代码的XiP执行并用大容量D-Cache来加速对PSRAM中网络数据包缓冲区的访问。最后记住一点内存子系统的优化是一个迭代和权衡的过程。从芯片手册出发理解其能力边界然后结合你的具体应用场景通过测量性能计数器、分析map文件和调整链接脚本、Cache配置来找到那个最适合你的“甜蜜点”。CC35xx提供的灵活性正是为了让你能完成这种精细的调优从而打造出性能、功耗和成本都更具竞争力的产品。
1. 项目概述在嵌入式无线MCU的开发中内存配置往往是最容易被忽视却又对系统性能、功耗和稳定性影响最深远的环节。很多工程师拿到一款像TI CC35xx这样的高性能无线MCU第一反应是去研究其Wi-Fi 6和蓝牙低功耗的射频性能却容易忽略其复杂而精妙的内存子系统MEMSS。实际上对于需要处理复杂网络协议栈、进行实时数据处理或运行轻量级操作系统的应用来说不合理的内存配置轻则导致性能瓶颈重则引发难以调试的随机崩溃。CC35xx系列提供了高度灵活的内存架构包括可动态划分的片上SRAM、用于加速的外部存储器Cache、以及支持片上执行XiP和实时加解密OTFDE的外部Flash/PSRAM接口。理解这套子系统意味着你能从芯片层面榨取每一分性能并构建出更稳定、更省电的产品。本文将结合手册内容与实际开发经验为你拆解CC35xx内存子系统的每一个核心模块并提供从原理到配置再到避坑的完整指南。2. 内存子系统整体架构与设计思路CC35xx的内存子系统设计遵循了经典的存储层次结构理念旨在平衡速度、容量、功耗和成本。其核心思路是利用高速、低延迟的片上SRAM作为“工作台”而将大容量的代码和数据存放在外部串行存储器中并通过缓存Cache和直接内存访问DMA等机制来弥合两者之间的速度鸿沟。2.1 核心组件与访问路径从系统框图来看CC35xx的MEMSS是一个以Cortex-M33核心为中心连接多种存储介质和总线主设备的复杂网络。我们可以将其主要组件和访问关系梳理如下主控核心M33 MCU系统的“大脑”负责指令取指和数据读写。它通过系统总线如C-AHB, S-AHB访问所有内存。片上SRAM这是性能的基石。CC35xx提供了高达1024KB的片上SRAM并在所有低功耗模式除关机模式外下保持数据。它被进一步细分为ITCM (Instruction Tightly Coupled Memory)指令紧耦合内存。用于存放对延迟极度敏感的关键代码如中断服务程序、实时控制循环。CPU可以无等待周期地访问ITCM。DTCM (Data Tightly Coupled Memory)数据紧耦合内存。用于存放需要被频繁、快速访问的关键数据如协议栈的控制块、实时传感器数据缓冲区。DMEM (Data Memory)通用数据内存。用于存放全局变量、堆栈、以及不那么紧急的数据。I-Cache (Instruction Cache)指令缓存。用于缓存从外部Flash或PSRAM中取出的指令减少访问延迟。D-Cache (Data Cache)数据缓存。专门用于加速对PSRAM中数据的访问。外部存储器串行Flash容量可达64MB其中8MB支持XiP执行用于存储程序代码、常量以及需要掉电保存的数据如网络配置、OTA镜像。它可以是外置的也可以是堆叠在封装内的。串行PSRAM容量可达64MB仅支持堆叠封装。这是一种易失性内存主要用于扩展数据存储空间例如存放大的音频缓冲区、图形帧缓冲区或协议栈的临时数据。特别注意PSRAM不能用于XiP执行代码。访问代理与仲裁µDMA (外部DMA)这是一个专用于在外部存储器Flash/PSRAM和片上SRAM之间搬运数据的DMA控制器。它有两个通道可以配置为安全或非安全能显著减轻CPU在数据搬运上的负担例如在OTA升级时从Flash读取新固件到SRAM。主机DMA用于在外设如ADC, SPI和片上SRAM之间传输数据。外部内存仲裁器 (EMA)当I-Cache取指、D-Cache访问PSRAM数据和µDMA数据搬运同时需要访问外部存储器时由EMA来仲裁访问权限。其优先级顺序为I-Cache (最高) D-Cache (中) µDMA (最低)。这确保了代码执行的实时性优先于数据访问。2.2 内存模式启动时的关键抉择CC35xx在启动时Boot允许开发者选择不同的“内存模式”这决定了片上SRAM资源在I-Cache/ITCM和D-Cache/DTCM之间的分配比例。这是一个一次性、不可运行时更改的配置直接影响后续所有软件的性能特征。手册中提到了几种模式其中对用户开放的主要是Mode 0 (基线模式)和Mode 5 (无BLE扩展M33数据模式)。我们以最常用的Mode 0为例其配置灵活性体现在两个独立的决策上决策一指令侧分配 (I-Cache vs. ITCM)你有64KB的指令侧高速存储资源可以将其全部用作I-Cache也可以拆分成两部分。选项A: 64KB I-Cache 0KB ITCM这是“性能优先”选项。大的I-Cache能更好地缓存外部Flash中的代码尤其适合代码量大、分支多的复杂应用能有效提升XiP执行的效率。选项B: 32KB I-Cache 32KB ITCM这是“确定性优先”选项。将32KB关键代码如网络协议栈的核心部分、实时中断处理锁定在ITCM中确保其执行时间绝对可预测不受缓存命中/未命中的影响。剩余的32KB I-Cache用于缓存其他代码。如何选择如果你的应用有严格的实时性要求例如电机控制、精确时序的无线通信或者有一部分代码的执行频率极高那么分配一部分ITCM是明智的。否则全部用作I-Cache通常能获得更好的整体性能。决策二数据侧分配 (D-Cache vs. DTCM)你有128KB的数据侧紧耦合存储资源可以在DTCM和D-Cache之间分配。选项A: 128KB DTCM 0KB D-Cache所有数据都放在高速DTCM中访问最快但容量有限。适合数据量不大但对访问速度要求极高的场景。选项B: 96KB DTCM 32KB D-Cache折中方案。将最热的数据放在DTCM同时用D-Cache来加速对PSRAM中较大数据集的访问。选项C: 64KB DTCM 64KB D-Cache偏向于处理PSRAM中大容量数据的场景。用较大的D-Cache来提升对PSRAM的访问效率牺牲一部分DTCM的绝对速度。如何选择这取决于你的数据访问模式。如果你的应用有大量数据需要存放在PSRAM中如图像处理、音频缓冲并且访问具有局部性反复访问同一块数据那么配置较大的D-Cache收益明显。如果数据量小但访问随机且频繁则应倾向于更大的DTCM。实操心得模式选择的权衡在实际项目中我通常采用“性能剖析迭代调整”的方法。首先基于应用特点做一个初步选择例如物联网网关代码量大选64KB I-Cache需要处理摄像头数据选64KB D-Cache。然后在SDK提供的内存链接脚本.cmd文件中精确定义哪些函数/数据段放到ITCM/DTCM。最后利用芯片的性能计数器如Cache命中/未命中计数器来验证配置的有效性必要时进行调整。记住没有“最好”的模式只有“最适合”你当前应用的模式。3. 核心组件深度解析与配置要点3.1 SRAM分区与链接脚本配置理解了内存模式后下一步就是通过链接器脚本Linker Script将你的代码和数据精确地放置到合适的内存区域。这是将硬件配置转化为软件性能的关键一步。ITCM/DTCM的链接脚本实践以TI的CCS或IAR开发环境为例你需要修改链接器命令文件.cmd。以下是一个简化的示例展示了如何将特定段分配到ITCM和DTCM/* 内存区域定义 (对应硬件地址) */ MEMORY { /* 程序存储器 */ FLASH (RX) : origin 0x00000000, length 0x00800000 /* 8MB 可执行Flash */ ITCM (RX) : origin 0x00000000, length 0x00008000 /* 32KB ITCM注意地址可能与FLASH重叠由总线区分 */ /* 数据存储器 */ SRAM (RW) : origin 0x20000000, length 0x00040000 /* 256KB 通用DMEM */ DTCM (RW) : origin 0x20040000, length 0x00020000 /* 128KB DTCM */ /* 外部PSRAM (非可执行) */ PSRAM (RW) : origin 0x80000000, length 0x00400000 /* 4MB PSRAM */ } /* 段放置 */ SECTIONS { /* 将中断向量表和最关键的启动代码放入ITCM确保最快响应 */ .intvecs : ITCM .text:fastcode : { *(.text:fastcode) } ITCM /* 使用section属性标记的关键函数 */ /* 主程序代码放在Flash中通过I-Cache加速 */ .text : FLASH /* 将频繁访问的全局变量、协议栈控制块放入DTCM */ .data:critical : { *(.data:critical) } DTCM .bss:critical : { *(.bss:critical) } DTCM /* 堆栈通常也放在DTCM以获得确定性的访问速度 */ .stack : DTCM /* 普通全局变量和堆放在通用SRAM */ .data : SRAM .bss : SRAM /* 大块数据如音频缓冲区放入PSRAM */ .psram_data : PSRAM }在C代码中你可以使用GCC/ARMCC的section属性来将特定函数或变量分配到自定义段// 将关键函数放入ITCM __attribute__((section(.text:fastcode))) void critical_isr_handler(void) { // ... } // 将高频访问变量放入DTCM __attribute__((section(.data:critical))) uint32_t protocol_state;3.2 D-CachePSRAM的性能加速器D-Cache是CC35xx针对PSRAM访问优化的核心部件。它不像通用CPU的Cache那样透明需要开发者进行显式的区域管理和一致性维护。3.2.1 可缓存区域配置D-Cache最大支持8MB的可缓存Cacheable区域管理粒度是4KB页。你需要通过配置寄存器DCACHE.CAL和DCACHE.CAH来定义PSRAM中哪一段地址范围是Cacheable的。Cacheable区域对此区域的读写会经过D-Cache。如果数据在Cache中Hit则直接高速访问如果不在Miss则会从PSRAM读取一整行Line数据到Cache中Read Allocate。写操作采用回写Write Back策略即先只更新Cache并标记为“脏”Dirty直到该Cache行被替换时才写回PSRAM。Non-Cacheable区域对此区域的访问将绕过Cache直接访问PSRAM。适用于那些只写一次或很少访问或者需要被其他主设备如DMA直接访问的数据以避免Cache一致性问题。配置示例假设你的PSRAM地址从0x8000_0000开始你希望将前2MB0x8000_0000到0x801F_FFFF配置为Cacheable用于存放需要频繁计算的中频数据而后面的部分作为Non-Cacheable用于存放原始采集数据或DMA缓冲区。// 设置Cacheable区域低地址 (按4KB对齐) HWREG(DCACHE_BASE DCACHE_O_CAL) 0x80000000 12; // 取高20位[31:12] // 设置Cacheable区域高地址 HWREG(DCACHE_BASE DCACHE_O_CAH) 0x801FFFFF 12; // 使能D-Cache HWREG(DCACHE_BASE DCACHE_O_CTRL) | DCACHE_CTRL_CENABLE;3.2.2 Cache一致性维护这是使用D-Cache时最容易出错的地方。由于Cache的存在PSRAM中的“真实”数据可能落后于Cache中的“副本”。在以下情况你必须手动维护一致性DMA数据传输当µDMA或主机DMA直接向PSRAM的Cacheable区域写入数据时这些新数据不会自动反映到D-Cache中导致CPU读到的还是旧数据。解决方案是在DMA传输完成后无效化Invalidate对应地址范围的Cache行。CPU修改共享数据如果CPU修改了Cacheable区域的数据这些修改可能还停留在Cache里脏数据。如果此时其他主设备如另一个CPU核或DMA需要读取PSRAM中的最新数据它们读到的将是旧值。解决方案是在CPU写操作后如果需要立即可见则进行写回Flush操作或者在其他主设备读取前由CPU执行Flush。CC35xx的D-Cache提供了相应的控制寄存器Flush (刷新)将Cache中所有被标记为“脏”Dirty的数据行写回到PSRAM然后清除脏标志。DCACHE.CTRL1.FLUSH位。Invalidate (无效化)直接丢弃Cache中指定区域的数据行下次访问时将重新从PSRAM加载。DCACHE.CTRL1.INVALIDATE位。通常在使能D-Cache前或DMA向Cacheable区域写入数据后需要对相应区域进行Invalidate。注意事项Cache操作的成本Flush和Invalidate是批量操作可能会消耗数百甚至上千个时钟周期阻塞CPU。因此应避免在频繁执行的代码路径或实时中断中进行全局的Cache维护。最佳实践是精细化管理只为真正需要维护的、较小的内存范围如一个DMA缓冲区执行Cache操作。异步处理在系统空闲或低优先级任务中执行全局Cache维护。利用非缓存区域对于频繁被DMA访问的共享数据区直接将其定义为Non-Cacheable虽然牺牲了速度但彻底避免了一致性问题简化了软件设计。3.3 外部存储器接口xSPI与拓扑选择CC35xx通过xSPI控制器连接外部Flash和PSRAM。xSPI支持多种工作模式直接影响访问带宽和引脚占用。3.3.1 工作模式传统SPI (1-bit)速度最慢引脚最少CLK, CS, MOSI, MISO。QSPI (Quad SPI, 4-bit)数据线增至4条在相同时钟频率下理论带宽是SPI的4倍。这是最常用的平衡模式。OSPI (Octal SPI, 8-bit)数据线增至8条带宽最大但需要占用更多MCU引脚D[7:0], DQS等。3.3.2 拓扑结构与电压配置这是硬件设计时必须仔细核对的部分。手册中列出了5种拓扑选择取决于你的Flash/PSRAM是外置还是堆叠以及是QSPI还是OSPI。拓扑编号Flash类型PSRAM类型XiP模式VDDSF (Flash电源)VIO2 (PSRAM CS等)关键约束1外置 QSPI Flash无外部 QSPI1.8V 或 3.3V独立 (1.8V/3.3V)最灵活电压可独立选择。2外置 OSPI Flash无外部 OSPI1.8V 或 3.3V必须与VDDSF相同使用OSPI时高4位数据线(D[7:4])和DQS由VIO2供电故电压需一致。3堆叠QSPI Flash无堆叠 QSPI必须为1.8V独立 (1.8V/3.3V)堆叠Flash固定为1.8V。XiP引脚内部连接外部引脚可用作GPIO。4外置 QSPI Flash堆叠QSPI PSRAM外部(QSPI) 堆叠(QSPI)必须为1.8V必须为1.8V堆叠PSRAM为1.8V且其片选(CS)信号在VIO2域故VIO2也必须为1.8V。5外置 OSPI Flash堆叠QSPI PSRAM外部(OSPI) 堆叠(QSPI)必须为1.8V必须为1.8V同拓扑4Flash用OSPI模式以获得更高带宽。设计建议追求高性能如果代码体积大需要快速XiP选择拓扑5外置OSPI Flash 堆叠PSRAM能最大化Flash读取带宽。追求成本与引脚优化如果代码量适中且需要额外RAM选择拓扑4外置QSPI Flash 堆叠PSRAM在性能和引脚数间取得平衡。最简单设计如果不需要PSRAM选择拓扑1外置QSPI Flash硬件设计最简单电压选择灵活。重要只要使用堆叠的PSRAMVDDSF和VIO2必须都连接到1.8V电源。这是一个常见的硬件设计陷阱。3.4 XiP、OTFDE与安全执行XiP (eXecute in Place) 允许CPU直接从外部Flash取指执行无需先将代码拷贝到SRAM。这节省了宝贵的SRAM空间但Flash的读取速度较慢因此需要I-Cache来加速。3.4.1 OTFDE实时加解密引擎OTFDE (On-The-Fly Decryption Encryption) 是CC35xx的一个安全增强特性。它可以在代码从Flash读取到I-Cache的过程中或数据在Flash与系统间传输时进行实时的AES-128加解密。应用场景保护知识产权将核心算法代码加密后存储在Flash中防止被轻易读取和反编译。安全启动确保只有经过签名的加密固件才能被正确解密和执行。安全存储对存储在Flash中的敏感数据如Wi-Fi密码、证书进行加密。工作原理OTFDE将外部Flash地址空间划分为多个独立的区域至少4个每个区域可以配置独立的密钥KEY和初始化向量IV。当CPU或DMA访问某个加密区域时OTFDE硬件自动进行解密当写入数据时则自动加密。对于非加密区域可以配置为旁路Bypass模式。配置流程简述在安全环境中如工厂生产时生成并烧录AES密钥和IV到芯片的安全存储区。在软件中通过配置OTFDE寄存器将Flash的特定地址范围映射到某个密钥区域并设置访问权限安全/非安全只读/可写。使能OTFDE。此后对该区域的访问将自动享受加解密服务。3.4.2 使用XiP的注意事项性能考量即使有I-CacheXiP的执行速度也永远比不上从ITCM或SRAM直接执行。对于最关键的实时循环或中断服务程序仍应考虑放入ITCM。功耗考量每次Cache未命中都需要访问外部Flash这会增加功耗。在低功耗应用中需要仔细评估代码布局提高Cache命中率。链接脚本调整启用XiP后链接脚本中.text代码段的目标地址应设置为Flash的地址范围如0x0000_0000开始而不是SRAM地址。4. 寄存器详解与底层驱动实现手册中提供了大量关于ICACHE和DCACHE的寄存器描述。作为开发者我们不需要记忆每一个位域但需要理解关键寄存器的作用以便进行调试和高级优化。这里我们重点看几个最常用的。4.1 Cache控制与状态寄存器ICACHE.CTRL / DCACHE.CTRL控制寄存器的核心是使能位CENABLE和RAM使能位RENABLE。CENABLE1使能Cache控制器。RENABLE此位含义在I-Cache和D-Cache中不同。对于I-CacheRENABLE1表示将一半Cache空间32KB用作RAM即ITCM另一半32KB用作Cache。RENABLE0表示全部64KB用作Cache。此位在CENABLE置1后即被写保护必须在使能Cache前配置好。对于D-Cache逻辑类似用于在DTCM和D-Cache间分配128KB资源。ICACHE.STATUS / DCACHE.STS状态寄存器。最重要的位是OK_TO_GO。在软件配置完Cache设置地址范围、模式等并使其能后需要轮询此位直到它变为1表示Cache内部初始化如Tag RAM初始化完成可以正常操作。Cache地址范围寄存器 (CAL,CAH)定义了Cacheable区域。如前所述需要按4KB对齐即地址的低12位为0。配置时写入的是地址的[31:12]位。4.2 性能监控与调试寄存器这是进行性能分析和优化的宝贵工具。HIT_COUNTER / MISS_COUNTER (ICACHE)和READ_COUNTER / WRITE_COUNTER (DCACHE)这些计数器分别记录了Cache的命中Hit和未命中Miss次数。应用在代码的关键路径前后读取这些计数器可以定量分析Cache配置的有效性。例如优化函数布局或调整Cacheable区域后观察命中率是否提升。注意计数器达到最大值后会停止。软件可以写入0将其清零。CACHE_FSM_STATE (DCACHE)这个寄存器以编码形式显示了D-Cache内部有限状态机FSM的当前状态。状态包括空闲WIDLE、读命中WCREADT、写回PSRAMEVICT等。在调试复杂的Cache一致性问题时观察FSM状态有助于理解Cache正在进行的操作。ADDRESS_LATCH (DCACHE)当D-Cache从OTFDE接收到AHB错误通常是由于访问了未配置或权限错误的加密区域时出错的访问地址会被锁存到这个寄存器中。这对于调试OTFDE配置错误非常有用。4.3 中断与错误处理寄存器IRQSTATUS_RAW / IRQENABLE_SET 等这些寄存器用于管理Cache相关的错误中断例如配置寄存器在锁定后被错误写入LOCK_CFG_WR。在可靠性要求高的系统中可以使能这些中断并在中断服务程序中进行错误记录或系统恢复。一个典型的D-Cache初始化与配置代码片段可能如下所示#include stdint.h #include “hw_memmap.h” #include “hw_types.h” #include “dcache.h” void DCacheConfigAndEnable(uint32_t cacheableBase, uint32_t cacheableSize) { // 1. 确保传入参数4KB对齐 assert((cacheableBase 0xFFF) 0); assert((cacheableSize 0xFFF) 0 cacheableSize 0); // 2. 计算并设置Cacheable区域的高/低地址 (取高20位) uint32_t cal cacheableBase 12; uint32_t cah (cacheableBase cacheableSize - 1) 12; // 3. 在使能前配置地址范围和模式假设选择64KB D-Cache模式 // 注意以下寄存器地址和位域定义需参考具体SDK头文件 HWREG(DCACHE_BASE DCACHE_O_CAL) cal; HWREG(DCACHE_BASE DCACHE_O_CAH) cah; // 配置CTRL寄存器使能Cache并选择64KB D-Cache模式 (RENABLE0) HWREG(DCACHE_BASE DCACHE_O_CTRL) DCACHE_CTRL_CENABLE; // RENABLE默认为0 // 4. 使能后等待Cache初始化完成 while(!(HWREG(DCACHE_BASE DCACHE_O_STS) DCACHE_STS_OK_TO_GO)) { // 可选加入超时机制 } // 5. 可选使能前无效化整个Cache区域以确保数据一致性 HWREG(DCACHE_BASE DCACHE_O_CTRL1) | DCACHE_CTRL1_INVALIDATE; while(HWREG(DCACHE_BASE DCACHE_O_STS1) DCACHE_STS1_INVALIDATE_STATUS) { // 等待无效化完成 } }5. 常见问题、调试技巧与实战心得在实际项目中使用CC35xx的MEMSS时会遇到各种问题。下面是我总结的一些典型场景和解决方法。5.1 问题排查速查表问题现象可能原因排查步骤与解决方案系统随机崩溃或数据错误尤其在DMA操作后。D-Cache一致性问题。DMA直接写入PSRAM的Cacheable区域但CPU的D-Cache中仍是旧数据。1. 检查DMA目标地址是否在DCACHE.CAL/CAH定义的Cacheable区域内。2. 在DMA传输完成中断中对目标缓冲区地址执行CacheInvalidate()。从Flash XiP执行代码时性能远低于预期。I-Cache未命中率过高。代码过于分散或I-Cache太小。1. 使用ICACHE的MISS_COUNTER验证未命中次数。2. 优化链接脚本将热点函数集中放置利用空间局部性。3. 考虑分配一部分ITCM给最关键的循环。使能OTFDE后访问特定Flash区域触发硬件错误。OTFDE区域配置错误或密钥/IV不匹配。1. 检查ADDRESS_LATCH寄存器获取触发错误的访问地址。2. 核对OTFDE区域配置寄存器确保访问地址落在已正确配置密钥和权限的区域。3. 确认使用的密钥和IV与加密固件时使用的完全一致。系统从低功耗模式唤醒后运行异常。SRAM数据丢失或Cache状态错乱。1. 确认唤醒源对应的低功耗模式是否支持SRAM保持Shutdown模式不支持。2. 在进入低功耗模式前如果D-Cache中有脏数据且对应PSRAM会掉电必须执行CacheFlush()。3. 唤醒后在访问Cacheable的PSRAM区域前先执行CacheInvalidate()。配置了D-Cache但访问PSRAM速度没有改善。1. 访问地址不在Cacheable区域。2. 访问模式是随机的没有局部性。3. D-Cache未成功使能。1. 检查DCACHE.CAL/CAH配置和实际访问地址。2. 检查DCACHE.STS.OK_TO_GO位是否为1。3. 优化数据结构与访问模式尽量顺序访问。使用堆叠PSRAM时系统无法启动或访问失败。VDDSF/VIO2电源电压配置错误。1.硬件检查确认使用堆叠PSRAM时VDDSF和VIO2是否都连接到了1.8V电源拓扑4/5。这是最常见的硬件错误。2.软件检查确认SDK中关于堆叠PSRAM的初始化序列已正确执行。5.2 调试技巧与高级优化利用性能计数器进行剖析在开发阶段定期读取HIT_COUNTER和MISS_COUNTER。计算命中率Hit Rate Hits / (Hits Misses)。针对命中率低的代码段分析其访问模式。是循环太大还是指针跳跃访问尝试调整算法或数据布局。Non-Cacheable区域的巧妙使用不要试图将所有PSRAM都设为Cacheable。将DMA缓冲区、频繁被其他主设备访问的共享数据区设置为Non-Cacheable可以彻底避免一致性烦恼虽然损失一点速度但换来了软件的简洁和稳定。链接脚本的精细打磨不要满足于默认的链接脚本。使用__attribute__((section(“xxx”)))将性能关键的函数和数据精确放置。工具链的map文件是你的好朋友仔细研究它确保关键部分确实放在了ITCM/DTCM。低功耗模式下的Cache处理在进入深度睡眠SRAM保持前如果PSRAM也会掉电必须将D-Cache中的脏数据写回Flush。唤醒后由于PSRAM内容可能无效或已改变需要将对应的Cache区域无效化Invalidate。这是一个容易忽略的细节会导致唤醒后数据错误。与RTOS的协同如果使用FreeRTOS等RTOS需要注意任务堆栈的分配。将中断栈和最高优先级任务的栈放在DTCM中可以保证最坏情况下的响应时间。RTOS的堆heap如果用于频繁动态分配放在通用SRAM或PSRAM中可能更合适。5.3 关于内存模式选择的个人体会经过多个项目的实践我形成了一些经验性的选择策略通用物联网节点传感器数据采集无线传输代码量中等实时性要求一般。我会选择Mode 0配置为 64KB I-Cache 0KB ITCM以及 96KB DTCM 32KB D-Cache。将协议栈的发送/接收缓冲区、加密上下文等放入DTCM将采集到的历史数据缓存放入PSRAM并用D-Cache加速。实时性要求高的控制器如电机控制代码量不大但对中断响应时间要求苛刻。我会选择Mode 0配置为 32KB I-Cache 32KB ITCM以及 128KB DTCM 0KB D-Cache。将PWM控制算法、位置环PID计算函数和中断向量表放入ITCM将所有控制变量和实时数据放入DTCM放弃D-Cache以简化设计。富功能网关设备运行轻量级Linux或复杂协议栈代码量巨大需要处理大量网络数据包。我会选择Mode 0配置为 64KB I-Cache 0KB ITCM以及 64KB DTCM 64KB D-Cache。最大化I-Cache来加速大型代码的XiP执行并用大容量D-Cache来加速对PSRAM中网络数据包缓冲区的访问。最后记住一点内存子系统的优化是一个迭代和权衡的过程。从芯片手册出发理解其能力边界然后结合你的具体应用场景通过测量性能计数器、分析map文件和调整链接脚本、Cache配置来找到那个最适合你的“甜蜜点”。CC35xx提供的灵活性正是为了让你能完成这种精细的调优从而打造出性能、功耗和成本都更具竞争力的产品。
在深度学习部署中的突破与应用)
