1. 项目概述与Bootcfg模块定位在基于德州仪器TIKeystone II架构的66AK2Hxx系列多核DSP上进行嵌入式开发尤其是涉及底层驱动、系统启动流程优化或功耗管理时你迟早会与一个名为“Bootcfg”的模块打交道。这个模块全称Boot and Configuration远不止其名字所暗示的“启动配置”那么简单。它实际上是芯片上电后在ROM代码执行阶段及后续整个系统生命周期中一个至关重要的硬件控制和状态管理单元。你可以把它理解为一个集成了电源管理、复位控制、核间通信IPC、中断路由、时钟选择乃至USB PHY调校的“系统控制中枢”。我最初接触66AK2H14时也曾以为启动配置无非就是设置一下启动引脚、加载个二级引导程序。直到在调试一个复杂的低功耗应用时系统从休眠模式唤醒后行为异常才被迫深入挖掘Bootcfg的数据手册。我发现很多高级功能比如让特定DSP核从深度休眠中恢复执行特定代码、精确控制看门狗超时后的复位行为、或者高效地在8个C66x DSP核与ARM Cortex-A15核之间传递事件其开关和参数都藏在Bootcfg那一大堆寄存器里。官方数千页的技术参考手册TRM信息浩如烟海而Bootcfg章节往往是其中最“硬核”的部分之一寄存器位域描述虽然详尽但缺乏场景化的串联和实战解读。因此本文旨在充当一份“实战指南”。我不会简单罗列寄存器表格——那是手册的工作。我将结合自身在通信基站和雷达信号处理等项目中的踩坑经验聚焦于Bootcfg模块中最关键、最常被问及的几组寄存器PWRSTATECTL电源状态控制、NMIGRx非屏蔽中断生成、IPCGRx/IPCARx核间中断生成与应答、RSTMUXx复位多路复用以及USB_PHY_CTLxUSB物理层控制。我会拆解它们每个关键位域在真实系统中的作用分享配置时的“潜规则”和避坑要点并提供可直接嵌入你BSP板级支持包或底层驱动中的代码片段。无论你是在进行裸机开发还是在SYS/BIOS或Linux环境下工作理解这些寄存器都是进行深度系统定制和性能优化的必修课。2. 核心寄存器深度解析与设计逻辑Bootcfg模块的寄存器空间是内存映射的这意味着你可以像访问普通内存一样通过指针读写它们。在66AK2Hxx中其基地址通常是0x0262 0000。理解这些寄存器首先要明白它们服务的两大核心系统需求确定性控制和灵活的事件路由。确定性控制体现在对电源状态、复位源的精确管理灵活的事件路由则体现在中断和IPC机制上这是发挥多核芯片性能的关键。2.1 PWRSTATECTL系统休眠与唤醒的指挥棒PWRSTATECTL寄存器是管理芯片低功耗状态的核心。66AK2Hxx支持多种休眠模式Hibernation其本质是在保持部分关键上下文如某些寄存器、内存内容的同时关闭大部分时钟和电源域以极致省电。PWRSTATECTL寄存器就是告诉ROM代码和硬件“我打算怎么睡以及睡醒后去哪”。关键位域实战解读Hibernation Recovery Branch Address (位 31-10)这是最重要的字段之一。它定义了当芯片从休眠模式1或2唤醒时C66x CorePac如果Recovery Master位为0将要跳转执行的起始地址。注意这是一个22位的地址对应的是字节地址的高22位。这意味着你提供的地址必须是64KB对齐的低16位为0。例如如果你想跳转到0x10800000你需要写入的值是0x10800000 10 0x042000取高22位。配置错误会导致唤醒后跑飞。避坑提示确保你设置的恢复地址所在的存储区域如DDR3、MSMC SRAM在休眠期间不会掉电并且该地址处已经存放了有效的可执行代码通常是唤醒后的初始化例程。Hibernation Mode / Hibernation (位 2, 1)这两个位共同定义了休眠状态。Hibernation位指示是否进入休眠Hibernation Mode位选择模式1或2。模式通常对应不同的功耗级别和唤醒源。关键操作顺序软件应先配置好其他所有参数如恢复地址、EMIF宽度等最后再置位Hibernation位来触发休眠动作。这个位一旦置起硬件状态机就会接管后续流程。Local Reset Action (位 6-5)这个字段决定了当某个C66x核接收到一个“本地复位”Local Reset事件时可能来自看门狗或RSTMUX配置该核的行为。选项包括进入空闲Idle、跳转到MSMC基地址、DDR3基地址或L2基地址。这是一个安全网。例如你可以配置为跳转到MSMC基地址在那里放置一个简单的错误处理或恢复程序防止核在异常复位后彻底死锁。Recovery Master (位 7)指定由谁ARM CorePac还是C66x CorePacs来执行休眠恢复流程。在多核异构系统中通常由ARM这类应用处理器作为主控来管理全局状态因此常设置为1由ARM负责唤醒后的系统重整。配置示例与心得假设我们设计一个场景系统由ARM主导进入休眠模式2唤醒后由ARM从DDR3的0x80000000地址开始执行恢复代码并且EMIF16总线配置为16位宽度、使能扩展等待。// 假设 BOOTCFG_BASE 已定义为 0x02620000 volatile uint32_t *pPwrStateCtl (uint32_t *)(BOOTCFG_BASE 0x00); // PWRSTATECTL 偏移地址需查手册确认 // 1. 计算并设置恢复地址高22位 (0x80000000 10 0x200000) uint32_t recovery_addr_field (0x80000000 10) 0x3FFFFF; // 掩码确保22位 // 2. 设置EMIF16宽度为16位扩展等待使能 uint32_t emif_config (1 9) | (1 8); // Width1, Wait1 // 3. 设置恢复主控为ARM本地复位动作为跳转至DDR3基地址 uint32_t ctrl_config (1 7) | (0x2 5); // Recovery Master1, Local Reset Action10b // 4. 设置休眠模式为模式2 uint32_t hibernation_config (1 2) | (1 1); // Hibernation Mode1, Hibernation1 (注意先不置位) uint32_t reg_value (recovery_addr_field 10) | emif_config | ctrl_config | hibernation_config; // 先写入配置但暂不触发休眠 *pPwrStateCtl reg_value (~(1 1)); // 确保Hibernation位为0 // ... 执行其他准备工作如保存上下文到非易失存储区配置唤醒源等 ... // 最后置位Hibernation位触发休眠 *pPwrStateCtl reg_value; // 此时Hibernation位为1芯片开始进入休眠流程重要提醒在实际进入休眠前必须确保所有核心都已进入协调状态相关外设已妥善关闭并且唤醒源如GPIO中断、定时器已正确配置。PWRSTATECTL的配置只是这个复杂流程的最后一步。2.2 NMIGRx与RSTMUXx非屏蔽中断与复位管理的精密配合NMIGRx寄存器提供了一种从外部或其他核心向特定C66x CorePac生成不可屏蔽中断NMI的硬件机制。NMI的优先级最高用于处理最严重的硬件错误或系统紧急事件。而RSTMUXx寄存器则将看门狗定时器事件与NMI、本地复位甚至设备全局复位关联起来形成一套可编程的故障响应链。NMIGRx寄存器实战这个寄存器极其简单只有最低位NMIG有效。向该位写1就会向对应的C66x核NMIGR0对应CorePac0以此类推发送一个NMI脉冲。它是“写1触发”型寄存器读操作永远返回0。这种设计避免了意外读取操作产生副作用。// 向C66x CorePac 2 发送一个NMI volatile uint32_t *pNmigr2 (uint32_t *)(BOOTCFG_BASE NMIGR2_OFFSET); *pNmigr2 0x1; // 写1触发NMI // 注意此操作通常由另一个核心如ARM或DMA等主机执行用于紧急通知或调试。RSTMUXx寄存器深度配置这才是重头戏。每个C66x核以及ARM核都有一个对应的RSTMUXx寄存器用于配置该核的看门狗事件响应策略。OMODE (位 3-1)操作模式选择这是核心。000b默认值看门狗事件无任何输出。相当于禁用此路看门狗的复位/NMI功能。010b看门狗事件直接触发本地复位。这是最常见的“看门狗复位”场景用于恢复“跑飞”的核。011b看门狗事件触发NMI。这给了软件一个“最后抢救”的机会。在NMI服务例程中可以尝试记录错误现场、保存关键数据然后再决定是否自行复位。100b先NMI后本地复位两者之间有可编程的延迟由DELAY字段控制。这是最灵活的策略。延迟时间允许NMI服务例程有足够的时间几百到几万个时钟周期执行紧急保存操作然后再被复位。101b看门狗事件触发整个设备全局复位。用于处理最严重的、影响整个芯片的故障。DELAY (位 7-5)当OMODE100b时此字段定义NMI触发后到本地复位触发之间的延迟周期数。延迟以SYSCLK1/6的周期为单位。例如SYSCLK1为1GHz则SYSCLK1/6约为166.7MHz周期约6ns。设置DELAY100b默认意味着4096个周期约24.6us的窗口期供NMI处理。LOCK (位 0)锁定位。一旦置1寄存器字段将被锁定直到下一次定时器复位看门狗复位或全局复位发生。这是一个重要的安全特性可以防止跑飞的软件意外修改看门狗响应策略。配置策略与示例对于一个高可靠性的信号处理从核我通常会采用OMODE100b先NMI后复位策略并设置一个合理的DELAY。// 配置 CorePac 1 的看门狗响应先NMI延迟约24.6us后复位 volatile uint32_t *pRstMux1 (uint32_t *)(BOOTCFG_BASE RSTMUX1_OFFSET); // OMODE 100b (先NMI后复位) DELAY 100b (4096 cycles) uint32_t config_value (0x4 1) | (0x4 5); // OMODE0x4, DELAY0x4 // 注意EVTSTATCLR和EVTSTAT位通常由硬件管理软件一般先读取EVTSTAT判断事件然后写EVTSTATCLR清除。 *pRstMux1 config_value; // 可选锁定配置防止被意外修改 *pRstMux1 config_value | 0x1; // 设置LOCK位避坑要点顺序问题务必在使能对应核的看门狗定时器之前先配置好RSTMUXx寄存器。否则第一个超时事件可能以你不希望的方式被处理。NMI服务例程如果使用NMI模式必须提前在C66x核的中断向量表中正确安装NMI服务例程ISR。该ISR应尽可能短小精悍只做最必要的现场保存例如用MVC指令保存一些关键CSR到安全内存避免复杂操作因为系统可能处于不稳定状态。ARM核的差异对于ARM Cortex-A15的看门狗其本地复位输出事件连接到PLL控制器的设备复位生成逻辑这意味着对ARM核的看门狗配置会影响更广泛的系统时钟需要格外小心。2.3 IPCGRx/IPCARx高效核间通信的硬件基石在多核DSP系统中核间通信IPC的性能至关重要。Bootcfg模块提供了硬件级的IPC生成与应答寄存器实现了非常高效的低开销核间中断。IPCGRx (IPC Generation Register)功能任何能访问Bootcfg空间的主机包括ARM、其他C66x核、DMA等都可以通过写IPCGRx寄存器来向目标核x发送一个中断脉冲。SRCSx (位 31-4)28位源标识符。这是IPC机制的精华所在。你可以用这28位来编码丰富的信息比如发送者的核ID、消息类型、甚至是一个小的数据标签。写入SRCSx位不仅会设置该位还会自动设置IPCARx寄存器中对应的SRCCx位。这实现了一个“置位-应答”的握手信号。IPCG (位 0)写1生成中断脉冲。与NMIG类似是写1触发。IPCARx (IPC Acknowledgment Register)功能用于查看和清除中断源状态。SRCCx (位 31-4)对应IPCGRx.SRCSx。读操作返回当前状态。写1到某一位会同时清除IPCARx.SRCCx和对应的IPCGRx.SRCSx位。这是接收核用来确认中断、清除中断源的机制。工作流程与软件协议假设CorePac 0 想通知 CorePac 1 处理一批数据并告知数据类型。发送方 (CorePac 0)// 定义协议SRCS[31:28]为源核ID(0)SRCS[27:24]为消息类型(0x1表示数据就绪) uint32_t ipc_message (0x0 28) | (0x1 24); volatile uint32_t *pIpcgr1 (uint32_t *)(BOOTCFG_BASE IPCGR1_OFFSET); // 设置源标识并生成中断 *pIpcgr1 (ipc_message 4) | 0x1; // 左移4位因为SRCSx从bit4开始接收方 (CorePac 1)它的中断服务例程被触发。ISR读取IPCAR1寄存器获取SRCCx字段解析出发送核ID和消息类型。根据消息类型处理数据。处理完成后必须清除中断源否则该中断源会一直有效。volatile uint32_t *pIpcar1 (uint32_t *)(BOOTCFG_BASE IPCAR1_OFFSET); uint32_t ack_reg *pIpcar1; uint32_t src_bits (ack_reg 4) 0x0FFFFFFF; // 提取SRCCx位 // ... 解析src_bits ... // 清除对应的中断源位假设我们清除所有位实际可能根据协议只清除特定的 *pIpcar1 ack_reg; // 写回当前值但SRCCx位写1才清除所以需要构造一个值。 // 更常见的做法是直接写一个值其SRCCx位对应需要清除的位为1。 // 例如要清除所有28个源位 *pIpcar1 0xFFFFFFF0; // 低4位是Reserved保持为0高28位全1写1清除。IPCGRH/IPCARH寄存器这两个寄存器功能与IPCGRx/IPCARx类似但用于向外部主机通过HOUT引脚发送中断或事件常用于芯片与外部FPGA或管理处理器之间的通信。实战经验性能通过写内存映射寄存器来触发中断比传统的通过共享内存设置标志再软件查询的方式延迟低得多是硬实时系统的首选。调试SRCSx位是强大的调试工具。你可以为不同的事件如“缓冲区满”、“任务完成”、“错误发生”分配不同的位接收方通过查看IPCARx就能快速定位事件来源无需复杂的软件日志。竞态条件虽然硬件保证了SRCSx和SRCCx的原子性置位/清除但软件协议仍需注意。例如发送方在极短时间内连续发送两条不同消息可能会覆盖前一条的SRCSx位。通常需要设计简单的软件确认机制或者使用不同的位来区分连续事件。2.4 其他关键寄存器点睛DEVSPEED寄存器这是一个只读寄存器用于在运行时查询芯片和ARM核的Speed Grade速度等级如800MHz, 1GHz, 1.2GHz。你的软件可以根据读出的值动态调整算法循环次数或超时参数实现跨不同型号芯片的二进制兼容。SYNECLK_PINCTL寄存器在网络应用中可能需要将某个SGMII端口的恢复时钟rxbclk路由到特定的时钟输出引脚TSRXCLKOUT0/1供板级其他芯片如PHY或另一个处理器同步使用。这个寄存器就控制这个路由选择。ARMENDIAN_CFGr_x寄存器当ARM以Little-Endian模式运行而访问某些Big-Endian格式的外设寄存器时可能会遇到字节序问题。这组寄存器允许为特定的内存区域通过BASEADDR和SIZE定义启用字节交换word swap使得ARM核总能以一致的字节序视图访问这些外设简化驱动开发。注意这通常用于解决特定外设IP的字节序问题并非全局设置。3. USB PHY控制寄存器组高速接口的调校秘籍USB_PHY_CTL0到USB_PHY_CTL5这组寄存器是专门用于精细调校USB 3.0/2.0物理层PHY参数的。在高速信号完整性要求极高的场合如通过USB 3.0进行高速数据采集这些寄存器的配置直接关系到链路是否能够稳定建立、眼图是否满足规范。为什么需要手动调校USB PHY在出厂时会有默认设置但PCB板上的走线长度、阻抗控制、过孔、连接器都会引入损耗和反射。在极端温度、电压下默认设置可能无法保证稳定的信号质量。此时就需要通过这些寄存器进行微调。关键调校参数实战USB_PHY_CTL2模拟前端调校PHY_PC_TXVREFTUNE(位 26-23): 调整高速模式下的发射器直流电平。如果接收端眼图垂直中心位置不对可以微调此参数。PHY_PC_TXRISETUNE(位 22-21): 调整高速信号的上升/下降时间。边沿太缓可能导致码间干扰太陡可能加剧EMI。PHY_PC_TXPREEMPAMPTUNE/PULSETUNE(位 17-16, 位18):预加重控制。这是应对高频损耗最重要的手段。预加重通过在信号跳变时增加瞬时驱动强度来补偿信道对高频分量的衰减。AMPTUNE控制增强的幅度PULSETUNE控制增强的持续时间。通常需要结合示波器或误码率测试仪观察眼图张开度来调整。PHY_PC_SQRXTUNE(位 9-7): 调整接收端 Squelch静噪电路的阈值。信号电平低于此阈值将被视为无效噪声。在信号衰减较大的长距离或劣质线缆场景下可能需要降低此阈值以避免误静噪。USB_PHY_CTL3PCS层与LOS调校PHY_PC_PCS_TX_SWING_FULL(位 29-23): 设置SuperSpeed模式下的发射摆幅。这是满足USB 3.0发射机电气规范的关键。PHY_PC_LOS_LEVEL(位 4-0): 设置Loss-Of-Signal检测器的灵敏度。手册明确要求必须设置为0x9。随意更改可能导致链路无法正常检测到连接或断开。USB_PHY_CTL4/5时钟与PLL配置PHY_FSEL(位 27-22):必须正确设置以匹配你提供给USB PHY的参考时钟频率如19.2MHz, 20MHz, 25MHz, 26MHz等。设置错误会导致PHY无法锁定或通信速率异常。PHY_MPLL_MULTIPLIER(位 19-13, 15-9): MPLL倍频器控制与PHY_FSEL和PHY_REF_CLKDIV2共同决定最终的线路速率。PHY_SSC_EN(位 31): 扩频时钟使能。如果参考时钟本身已带扩频此处应禁用设为0否则可能造成双重调制影响时钟质量。调校流程建议保持默认首先在默认配置下测试链路如果能够稳定通过USB-IF合规性测试如眼图、抖动则无需调整。逐项微调如果发现问题如眼图闭合、误码率高优先调整PHY_PC_TXPREEMPAMPTUNE预加重幅度通常增加一档如从01b到10b会有改善。借助工具强烈建议使用网络分析仪TDR/TDT先测量PCB通道的S参数使用仿真工具如ADS预估所需的均衡预加重设置再进行硬件测试避免盲目尝试。记录配置将最终稳定的寄存器配置值固化到你的初始化代码中。不同批次的PCB或不同温度点可能需要不同的配置。4. 常见问题排查与调试技巧实录在实际项目中Bootcfg相关的问题往往表现为系统启动失败、休眠后无法唤醒、多核通信丢事件、或USB链路不稳定。以下是一些典型的排查思路和技巧。4.1 系统无法从休眠模式唤醒症状配置休眠后芯片功耗下降但触发唤醒事件后系统无反应。排查步骤检查恢复地址这是最常见的问题。使用调试器如TI的CCS在进入休眠前检查PWRSTATECTL寄存器中Hibernation Recovery Branch Address字段的值是否正确已右移10位。并确认该地址所在的存储器如DDR在休眠期间供电正常且地址处已预先加载了有效的唤醒恢复代码。验证唤醒源确认你期望的唤醒源如GPIO中断、RTC定时器已正确使能并且在休眠模式下其时钟域仍然工作。有些唤醒源需要特殊的引脚复用或时钟门控配置。检查Recovery Master如果设置由ARM核执行恢复Recovery Master1确保ARM核本身没有被置于深度休眠或关闭状态。同时ARM核的唤醒向量也需要正确设置。检查EMIF配置如果恢复地址位于通过EMIF16接口连接的外部Flash或RAM中确保Width和Wait位配置与实际硬件匹配。错误的位宽或等待周期会导致读取指令失败。4.2 核间中断IPC丢失或无法触发症状核A向核B发送IPC中断但核B的中断服务程序从未被调用。排查步骤确认寄存器映射首先确认你读写的IPCGRx和IPCARx寄存器地址偏移是正确的并且是针对目标核x的。检查中断使能Bootcfg的IPC机制只生成硬件中断脉冲。目标核C66x的中断控制器INTC必须已经使能了对应的中断输入通常是INT8到INT15具体映射需查芯片手册。这是最容易遗漏的一步你需要配置C66x CorePac的IER中断使能寄存器和ICR中断组合寄存器。检查SRCSx位发送方在写IPCGRx时除了置位IPCG是否也正确设置了SRCSx位接收方在ISR中是否读取了IPCARx的SRCCx位来确认事件清除中断源接收方ISR在处理完事件后必须通过写IPCARx清除对应的SRCCx位。否则该中断源会一直保持有效状态可能阻塞后续中断。一个常见的错误是只读了IPCARx而没有写回清除。使用调试器观察在CCS中可以实时监控IPCGRx和IPCARx寄存器的值。发送操作后观察SRCSx位是否置起接收方ISR执行后观察SRCCx位是否被清除。4.3 看门狗复位行为不符合预期症状使能看门狗后超时发生时没有产生复位或者产生了复位但系统状态异常。排查步骤确认RSTMUXx配置顺序必须在使能看门狗定时器之前配置好RSTMUXx寄存器。如果顺序反了第一次超时可能使用默认值OMODE000b无动作或未定义行为。检查OMODE和DELAY确认OMODE字段设置为你期望的模式如010b直接复位或100b先NMI后复位。如果选择了100b检查DELAY值是否合理。延迟太短NMI ISR可能来不及保存任何信息延迟太长系统在错误状态下运行过久。验证NMI ISR如果使用了NMI模式确保NMI中断向量已正确安装并且ISR代码尽可能简单、健壮。NMI ISR中应避免调用可能依赖已被破坏的系统状态的复杂函数。检查LOCK位如果你置位了LOCK位那么在下次复位前将无法修改RSTMUXx配置。这在产品固件中通常是期望的行为但在调试阶段可能会带来不便。调试时可先不锁定。4.4 USB 3.0链路训练失败或速率不达标症状USB 3.0设备无法被主机识别或者只能以USB 2.0高速模式连接。排查步骤检查基础时钟和电源使用示波器测量提供给USB PHY的参考时钟REFCLK频率和幅值是否稳定、符合要求通常为19.2MHz, 20MHz等。检查USB PHY的模拟电源AVDD和数字电源DVDD是否干净、纹波小。确认PHY_FSEL这是最关键的一步。根据你实际使用的REFCLK频率严格对照数据手册中的表格设置PHY_FSEL位域。一个错误的频率选择会导致PLL无法锁定链路训练根本不会开始。检查PCB设计USB 3.0 SuperSpeed差分对SSTX, SSTX-, SSRX, SSRX-要求严格的90欧姆差分阻抗控制、等长布线并远离噪声源。糟糕的PCB设计是链路失败的首要原因非寄存器配置所能弥补。进行眼图测试如果条件允许使用高速示波器和USB一致性测试软件进行眼图测试。观察眼图的张开度、抖动和噪声。如果眼图闭合再考虑调整USB_PHY_CTL2中的预加重TXPREEMPAMPTUNE和均衡设置。调整应有依据最好先仿真。查阅勘误表TI的芯片勘误表Silicon Errata中可能包含特定批次芯片USB PHY的已知问题和工作建议务必查阅。5. 实操构建一个健壮的多核启动与通信框架理解了各个寄存器后我们可以将其组合起来构建一个用于66AK2Hxx的底层框架。以下是一个简化的示例展示在系统初始化阶段如何配置这些关键部分。// bootcfg_driver.c #include stdint.h #include platform.h // 包含BOOTCFG_BASE等定义 #define BOOTCFG_PWRSTATECTL_OFFSET 0x00 // 示例偏移需查手册确认 #define BOOTCFG_NMIGR_OFFSET 0x20 // 示例 #define BOOTCFG_IPCGR_OFFSET(n) (0x40 (n)*4) // 示例 #define BOOTCFG_IPCAR_OFFSET(n) (0x80 (n)*4) // 示例 #define BOOTCFG_RSTMUX_OFFSET(n) (0x100 (n)*4) // 示例 void bootcfg_early_init(void) { // 1. 配置看门狗复位行为假设每个核独立看门狗 // 对于C66x核配置为先NMI后复位延迟约24.6us for (int core_id 0; core_id NUM_C66X_CORES; core_id) { volatile uint32_t *pRstMux (uint32_t *)(BOOTCFG_BASE BOOTCFG_RSTMUX_OFFSET(core_id)); uint32_t config (0x4 1) | (0x4 5); // OMODE100b, DELAY100b *pRstMux config; // 调试阶段暂不锁定 // *pRstMux config | 0x1; // 锁定 } // 2. 配置ARM核的看门狗响应如果需要 // 注意ARM的RSTMUX可能连接到不同的复位逻辑配置需谨慎。 // 3. 初始化IPC通信寄存器清除所有 pending 状态 for (int i 0; i NUM_IPC_REGISTERS; i) { volatile uint32_t *pIpcar (uint32_t *)(BOOTCFG_BASE BOOTCFG_IPCAR_OFFSET(i)); *pIpcar 0xFFFFFFF0; // 写1清除所有SRCCx位 } // 4. 配置USB PHY如果应用需要 // 假设使用19.2MHz参考时钟使能扩频 volatile uint32_t *pUsbPhyCtl4 (uint32_t *)(BOOTCFG_BASE USB_PHY_CTL4_OFFSET); uint32_t ctl4_val *pUsbPhyCtl4; ctl4_val ~(0x3F 22); // 清除FSEL字段 ctl4_val | (0x19 22); // 设置FSEL为19.2MHz对应的值查表 ctl4_val | (1 31); // 使能SSC *pUsbPhyCtl4 ctl4_val; // 5. 配置休眠恢复地址由ARM主核执行恢复 volatile uint32_t *pPwrCtl (uint32_t *)(BOOTCFG_BASE BOOTCFG_PWRSTATECTL_OFFSET); // 假设恢复代码在DDR的0x80000000ARM为恢复主控 uint32_t recovery_addr 0x80000000 10; uint32_t pwr_config (recovery_addr 10) | (1 7); // 设置地址和Recovery Master *pPwrCtl pwr_config (~(1 1)); // 不使能休眠 } // 用于核间通信的API void ipc_send_interrupt(uint32_t target_core_id, uint32_t message_tag) { if (target_core_id NUM_C66X_CORES) return; volatile uint32_t *pIpcgr (uint32_t *)(BOOTCFG_BASE BOOTCFG_IPCGR_OFFSET(target_core_id)); // 简单协议message_tag占据低28位 uint32_t ipc_value (message_tag 0x0FFFFFFF) 4; ipc_value | 0x1; // 置位IPCG位 *pIpcgr ipc_value; } uint32_t ipc_get_and_clear_sources(uint32_t core_id) { volatile uint32_t *pIpcar (uint32_t *)(BOOTCFG_BASE BOOTCFG_IPCAR_OFFSET(core_id)); uint32_t status *pIpcar; uint32_t sources (status 4) 0x0FFFFFFF; // 提取源标识 // 清除所有源位 *pIpcar 0xFFFFFFF0; return sources; }这个框架提供了最基本的初始化、IPC发送和接收功能。在实际产品中你需要根据具体的应用场景如哪些核需要休眠、IPC消息协议如何定义、看门狗超时时间等进行细化和扩展。最重要的是将这些底层的、硬件相关的配置与你的操作系统如SYS/BIOS或中间件如TI的IPC库进行整合确保整个系统的行为是协调和确定的。最后牢记一点Bootcfg的配置是系统级、全局性的且很多寄存器在复位后是只写一次或需要特定解锁序列的。在团队协作中最好由最底层的BSP或HAL硬件抽象层团队统一管理这些配置并形成详尽的文档避免不同驱动模块或应用层代码对其进行冲突的修改。
