1. 项目概述与核心挑战如果你正在接触TI的AM243x这类多核异构MCU并且被它复杂的启动流程和程序烧录搞得一头雾水那么这篇文章就是为你准备的。我最近在基于AM243x-LP评估板进行开发时花了大量时间才把从芯片上电到应用程序跑起来的整个链条彻底打通。这个过程远不止是点一下“编译”和“下载”那么简单它涉及到芯片内部的电源域管理、多级引导加载器Bootloader的协同、以及如何将程序正确地固化到外部Flash中。很多刚接触这类高性能MCU的工程师往往会在“我的程序怎么烧不进去”或者“为什么一断电程序就没了”这类问题上卡很久。今天我就以最常用的从板载OSPI Flash启动为例把AM243x的启动原理、SBL二级引导加载器的作用、以及如何通过UART将程序烧录到Flash的完整实操过程掰开揉碎了讲清楚。无论你是软件、硬件还是系统工程师理解这套流程都是玩转AM243x的必修课。2. AM243x启动流程深度解析要烧录和启动首先必须理解芯片是怎么“醒来”并找到你的程序的。AM243x的启动链可以概括为经典的三级接力ROM Bootloader (RBL) - Secondary Bootloader (SBL) - Application (APP)。但这简单的三步背后是多核异构架构带来的复杂协同。2.1 上电与引导模式一切的起点AM243x芯片内部有多个电源域为不同的处理器核心和外设供电。它不是简单的一上电所有部分都工作。上电时序是第一个关键电源必须按照特定顺序和电压要求稳定否则芯片可能无法正常复位或启动。在评估板上这部分通常由电源管理芯片PMIC妥善处理我们只需确保供电正常即可。当最后一个电源域稳定MCU_PORz上电复位引脚释放时芯片会做一件至关重要的事锁存SYS_BOOTMODE[0:15]这组引脚的状态。这16个引脚的状态通过上下拉电阻配置直接决定了芯片的启动模式和启动介质。这就像是告诉刚睡醒的芯片“去哪个房间哪种接口找你的第一份指令RBL”。注意在AM243x-LP评估板上这组Bootmode引脚连接到了一个8位的拨码开关SW3上。通过拨动开关我们可以直观地配置启动模式。设计自己的底板时必须参考技术参考手册TRM中的“Bootmode Pin Map”章节确保你希望使用的启动接口如OSPI、UART对应的引脚没有被其他功能占用并且正确配置了上下拉电阻。AM243x支持两大类启动模式主机启动模式芯片作为“从设备”等待外部主机如PC通过UART、Ethernet、USB等接口发送启动镜像。这常用于程序烧录和调试阶段。存储器启动模式芯片作为“主设备”主动从外部存储介质如OSPI Flash、SD卡、eMMC读取启动镜像。这是产品量产运行时的标准方式。此外芯片还贴心地设计了主备份启动机制。如果配置为主启动模式Primary Boot的介质读取失败比如Flash为空或损坏芯片会自动尝试切换到备份启动模式Backup Boot再次尝试。这提高了系统的可靠性。2.2 ROM引导加载器芯片的出厂固件上电复位后最先运行的是固化在芯片ROM中的代码即RBL。它的任务是进行最基础的初始化并根据Bootmode引脚配置从指定的外部接口寻找并验证下一阶段的引导程序即SBL。AM243x的RBL设计比较特别它分为两部分协同工作DMSC ROM Code这是运行在一个专用Cortex-M3核心称为DMSC设备管理与安全控制器上的固件。它是启动过程的“总指挥”。它的工作包括管理整个芯片的电源、时钟和安全状态。配置系统级的基础设施如防火墙、安全代理等。最重要的它控制着所有R5F应用核心的复位释放。也就是说在DMSC完成它的初始化之前R5F核心是“沉睡”的。Public ROM Code这部分是运行在第一个R5F核心R5FSS0-0上的固件。在DMSC释放其复位后它开始工作。它的核心职责是根据Bootmode配置驱动对应的外设如OSPI控制器、UART控制器。从外部介质如Flash或主机接口如UART接收SBL镜像数据。将接收到的数据提交给DMSC进行完整性校验使用SHA-512算法。这是安全启动的第一道关口。如果校验通过则配置PLL并将SBL镜像加载到指定的RAM地址通常是0x70000000然后跳转到那里执行。如果主启动失败则尝试备份启动。实操心得理解RBL的工作范围很重要。它只负责最基础的初始化和加载SBL。它不支持复杂的文件系统、也不负责加载多核APP。这些高级功能都需要由我们开发者提供的SBL来完成。因此如果你的SBL镜像本身格式不对、签名无效对于安全器件或加载地址错误RBL就会卡住表现为芯片“没反应”。2.3 二级引导加载器承上启下的关键SBL是我们开发者可以定制和编译的程序。它的核心使命是建立完整的软件运行环境并加载最终的用户应用程序。一个典型的SBL如SBL_OSPI会执行以下操作初始化基础外设例如初始化用于打印调试信息的UART控制台。加载系统固件调用Bootloader_socLoadSysFw()函数将TI提供的系统固件镜像加载到DMSC的RAM中并启动它。这个SYSFW包含了芯片所有底层资源的驱动和管理策略是多核通信、电源管理、时钟管理等服务的提供者。没有它多核应用无法正常运行。初始化启动介质例如对OSPI Flash控制器进行更复杂的配置如DDR模式、调优使其能以更高性能工作。解析并加载应用镜像从Flash的固定偏移地址例如0x80000读取多核应用镜像。这个镜像文件.appimage是一个复合镜像内部包含了每个核心R5FSS0-0, R5FSS0-1, R5FSS1-0, R5FSS1-1, M4F各自的代码、数据以及描述其加载地址和入口地址的元数据。分发应用SBL解析这些元数据将每个核心的代码段、数据段拷贝到它们各自指定的内存地址如DDR或片上RAM。释放其他核心SBL通过DMSC的IPC进程间通信服务请求释放其他所有应用核心的复位信号。跳转执行最后SBL引导所有核心从各自的入口地址开始执行用户应用程序完成启动接力。注意事项SBL自身的链接地址Entry Point是固定的由RBL决定通常是0x70000000。在编译SBL工程时必须在链接器命令文件中正确设置-e参数指向这个地址。同时SBL通常只运行在R5FSS0-0核心上因此需要在代码起始处将其他R5核心置于WFI等待中断状态防止它们跑飞。3. 开发环境搭建与SBL镜像生成理论清楚了我们开始动手。要让AM243x从OSPI Flash启动我们需要准备两样东西SBL镜像和APP镜像。这里先讲SBL。3.1 软件与工具准备你需要以下软件环境Code Composer StudioTI主推的集成开发环境用于编译工程。MCU SDK针对AM243x的软件开发包包含了所有外设驱动、示例和必要的工具链。请从TI官网下载对应版本。OpenSSL用于生成镜像签名。即使你的芯片不启用安全启动RBL也要求SBL镜像必须是经过签名的格式.tiimage。从 slproweb.com 下载Win64 OpenSSL Light版本安装即可。安装时记得勾选“将OpenSSL DLL复制到Windows系统目录”。Python 3用于运行UART烧录脚本。从官网下载安装务必在安装向导中勾选“Add Python to PATH”。安装后将OpenSSL的bin目录如C:\Program Files\OpenSSL-Win64\bin添加到系统的PATH环境变量中并在命令行验证python --version和openssl version能否正确执行。3.2 编译与生成SBL镜像SDK中提供了多种SBL示例我们选择SBL_OSPI。导入工程在CCS中选择Project - Import CCS Projects...导航到SDK路径下的\examples\drivers\boot\sbl_ospi文件夹导入工程。编译工程直接编译该工程。这会在项目的Debug或Release输出目录下生成一个.out文件如sbl_ospi_am243x-lp_r5fss0-0_nortos_ti-arm-clang.out。转换与签名.out文件不能直接用于启动需要经过两步转换转换为裸二进制使用ARM工具链中的objcopyCCS在编译时通常已自动生成同名的.bin文件将ELF格式的.out文件转换为纯二进制的.bin文件。签名生成TI镜像这是关键一步。我们需要使用SDK提供的签名脚本。打开Windows PowerShell注意不是CMD且可能需要以管理员身份运行导航到签名脚本目录cd C:\ti\mcu_plus_sdk_am243x_xx_xx_xx_xx\tools\boot\signing执行签名命令这里需要替换为你自己的.bin文件路径和名称.\x509CertificateGen.ps1 -b .\sbl_ospi_am243x-lp_r5fss0-0_nortos_ti-arm-clang.bin -o sbl_ospi_mine.tiimage -c R5 -l 0x70000000 -k .\rom_degenerateKey.pem -d DEBUG -j DBG_FULL_ENABLE -m SPLIT_MODE-b: 输入的.bin文件。-o: 输出的.tiimage文件名。-c: 核心类型R5。-l: 加载地址必须与SBL工程链接地址一致0x70000000。-k: 签名密钥使用SDK提供的默认测试密钥即可。-d,-j,-m: 调试和模式参数保持默认。执行成功后你会得到sbl_ospi_mine.tiimage文件这就是可以被RBL识别和加载的SBL镜像。避坑指南路径问题建议先将生成的.bin文件拷贝到signing目录下再执行命令避免因路径包含空格或特殊字符导致脚本执行失败。PowerShell执行策略公司电脑可能限制PowerShell脚本执行。如果报错可以尝试以管理员身份运行PowerShell并执行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser临时更改策略操作后请改回。镜像版本SDK的\tools\boot\sbl_prebuilt\am243x-lp\目录下已有预编译好的SBL镜像如sbl_ospi.release.tiimage。在初次验证时可以直接使用预编译镜像以排除自己编译引入的问题。4. 应用程序镜像生成与配置SBL准备好后我们需要一个最终要运行的用户程序这里以ADC单次采样例程为例。4.1 编译应用程序导入ADC例程在CCS中导入SDK中的ADC示例工程路径通常为\examples\drivers\adc\adc_singleshot\am243x-lp\r5fss0-0_freertos。编译工程编译后在输出目录如Debug下除了常见的.out文件你会找到一个非常重要的文件adc_singleshot_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage。.appimage文件这是通过SDK提供的tiarmimagegen工具生成的多核应用镜像。它内部打包了所有使能核心的程序代码、数据以及一个描述各段信息的文件头。SBL正是通过解析这个文件头才知道该把哪段代码加载到哪个地址、并启动哪个核心。4.2 理解镜像的存储布局现在我们有了一前一后两个镜像SBL.tiimage和APP.appimage。它们需要被烧录到OSPI Flash的特定位置SBL镜像必须烧录到Flash的起始地址0x0。因为RBL固定从启动介质的0地址开始加载数据。APP镜像默认烧录到偏移量0x80000512KB的位置。这个偏移量是SBL代码里写死的查找地址。你可以在SBL的源代码通常是sbl_main.c或相关的配置文件中修改这个地址但必须保证SBL和APP的存储区域没有重叠。这种布局确保了启动过程的确定性RBL从0读SBLSBL从0x80000读APP。5. 通过UART烧录OSPI Flash全流程实操这是最核心的实操环节。我们将使用评估板自带的XDS110调试器提供的UART接口配合Python脚本将SBL和APP镜像烧写到板载的OSPI Flash中。5.1 硬件连接与板卡配置连接线缆将评估板的Micro-USB口标记为XDS110连接到电脑。这个接口同时提供调试和UART串口功能。将评估板的USB Type-C口连接到电源适配器或电脑的USB口供电。建议使用能提供5V/2A以上电流的电源。配置启动模式将评估板上的拨码开关SW3设置为UART启动模式。根据板卡手册这通常是SW3.1 OFF (0), SW3.2 ON (1), SW3.3 OFF (0), SW3.4 ON (1)其余位保持默认。设置完成后给板卡重新上电或按下SW1复位键。识别串口在Windows设备管理器中查看“端口COM和LPT”你会看到XDS110 Class Application/User UART对应的COM号例如COM17。记下这个号码。5.2 准备烧录脚本与文件手动敲命令容易出错我习惯创建一个批处理文件来组织所有操作。在你的ADC例程工程目录下新建一个文件夹比如叫FlashProgram。收集必要文件将之前生成的或预编译的sbl_ospi.release.tiimageSBL镜像拷贝进来。从SDK的\tools\boot\目录拷贝uart_uniflash.py脚本文件进来。从SDK的\tools\boot\sbl_prebuilt\am243x-lp\目录拷贝sbl_uart_uniflash.release.tiimage文件进来。这个文件非常关键它是一个特殊的SBL运行后不引导APP而是作为一个“Flash烧写服务器”通过UART接收来自PC的烧录指令和数据。将ADC例程编译生成的adc_singleshot_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimageAPP镜像也放在方便引用的位置比如上一级目录的Debug文件夹。创建配置文件在FlashProgram文件夹内创建一个文本文件命名为ospi_sbl_app.cfg内容如下。这个文件告诉烧录脚本要做什么。# 首先指定烧写器镜像即那个特殊的SBL --flash-writersbl_uart_uniflash.release.tiimage # 操作1烧写OSPI PHY调优数据可选但建议进行以确保Flash性能 --operationflash-phy-tuning-data # 操作2在偏移量0x0处烧写主SBL镜像 --filesbl_ospi.release.tiimage --operationflash --flash-offset0x0 # 操作3在偏移量0x80000处烧写应用程序镜像 --file../Debug/adc_singleshot_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage --operationflash --flash-offset0x80000注意--file参数后的路径需要根据你实际的文件存放位置进行修改。创建批处理文件在同一目录下创建program.bat文件内容如下echo off echo echo 开始烧写 QSPI Flash... echo echo. python uart_uniflash.py -p COM17 --cfgospi_sbl_app.cfg echo. echo echo 烧写完成 echo echo. pause将COM17替换为你设备管理器中看到的实际COM端口号。5.3 执行烧录确保AM243x-LP板卡已配置为UART模式并重新上电。双击运行program.bat文件。观察命令行窗口的输出。脚本会依次执行以下动作通过UART发送sbl_uart_uniflash.tiimage到板卡并运行。此时板卡上的RBL会加载这个镜像。该镜像运行后会在串口打印信息等待主机连接。Python脚本与之建立连接然后根据.cfg文件指令依次将PHY调优数据、SBL主镜像、APP镜像通过UART发送给板卡上的“烧写服务器”。“烧写服务器”将这些数据写入到OSPI Flash的指定地址。看到“烧写完成”的提示且没有报错即表示成功。5.4 验证启动切换启动模式将评估板拨码开关SW3改回OSPI启动模式根据手册通常是SW3.1 ON (1), SW3.2 OFF (0), SW3.3 OFF (0), SW3.4 ON (1)。复位或重新上电按下SW1MCU_PORz复位键或者重新拔插Type-C电源线。观察串口输出打开一个串口终端软件如Tera Term、Putty连接到之前识别到的那个COM口波特率设置为115200。你应该会看到类似以下的输出[SBL] Starting Secondary Bootloader... [SBL] Loading SysFw... [SBL] SysFw Loaded Successfully. [SBL] Opening OSPI Flash... [SBL] Reading App Image from offset 0x80000... [SBL] Jumping to Application... [ADC Demo] ADC Single Shot Example Started. [ADC Demo] Raw Value: xxxx, Voltage: x.xx V.这表明RBL成功加载了SBLSBL成功加载并跳转了ADC应用程序整个RBL - SBL - APP的启动链条完美运行。6. 常见问题排查与调试技巧在实际操作中你可能会遇到各种问题。这里分享几个最常见的坑和排查思路。6.1 串口无任何输出检查供电确认Type-C电源已连接且LD9红灯没有常亮。用万用表测量板卡上3.3V等关键电源点电压是否正常。检查启动模式最常犯的错误。确认拨码开关SW3的设置与你想使用的启动模式完全一致并且在上电或复位前已设置好。可以对照评估板手册反复核对。检查串口连接确认使用的是“User UART”对应的COM口。确认终端软件参数波特率1152008数据位1停止位无校验无流控。尝试拔插USB线让系统重新识别端口。检查SBL镜像如果是在OSPI启动模式下无输出可能是SBL镜像本身有问题。尝试使用SDK预编译的sbl_ospi.release.tiimage进行烧录以排除自己编译、签名出错的可能。6.2 烧录脚本执行失败Python环境与依赖确保Python已正确安装并加入PATH。在管理员CMD中运行pip install pyserial xmodem tqdm确保依赖包齐全。COM端口占用关闭所有可能占用该串口的终端软件、CCS调试会话等。板卡状态确保执行脚本前板卡已处于UART启动模式并完成复位。可以观察串口是否有类似Waiting for flash writer...的提示输出。文件路径错误仔细检查.cfg文件和.bat文件中的路径是否正确尤其是相对路径..的使用。建议初期使用绝对路径避免混淆。6.3 SBL启动后卡住无法加载APP串口有SBL打印但无APP打印这通常是APP镜像烧录位置或镜像本身问题。检查烧录偏移量确认烧录APP时使用的--flash-offset与SBL代码中查找APP的偏移量是否一致默认都是0x80000。检查APP镜像确认烧录的是.appimage文件而不是.out或.bin文件。只有.appimage才包含多核加载信息。检查SBL调试信息在SBL源代码中增加更详细的日志打印出读取Flash的地址、镜像大小、校验结果等信息有助于定位是读取失败还是镜像解析失败。6.4 调试手段进阶使用CCS连接调试在SBL或APP的代码中设置断点通过CCS连接XDS110调试器可以单步执行查看变量、内存和寄存器状态这是定位复杂问题的终极手段。查看内存内容如果怀疑Flash内容不对可以在CCS的Memory Browser中直接查看OSPI Flash映射的内存地址范围例如0x60000000开始对比写入的数据和预期的镜像文件是否一致。利用ITM/SWO输出对于更深层次的、串口初始化前的调试可以配置芯片通过ITMInstrumentation Trace Macrocell和SWOSerial Wire Output引脚输出调试信息需要额外的硬件如J-Link和支持。整个流程走通后你会发现AM243x的启动虽然步骤繁多但逻辑清晰。关键在于理解每一级加载器的职责以及镜像文件的正确生成和放置位置。掌握了这套方法你就能 confidently 将你的应用程序部署到Flash中实现产品的独立上电运行。