使用器件 ti dsp c2000 2837x 1、dsp的上电过程和boot mode以及boot loader   1）dsp的上电顺序， 对于双核系统而言 ， 他的上电启动顺序如下所示：   系统复位或者重新上电之后：   cpu2系统重新上电之后，一直处于复位状态   cpu1系统会自动跳转到地址0x3fffc0中获取复位向量，福为向量的目的就是为了使得系统自动跳转到0X3F8000地址上，开始执行boot ROM 段中存储的boot loader代码段；   对于cpu1而言，cpu1的boot ROM段中的boot loader程序首先会从TI - OTP内存段中获取设备的配置自，并配置好器件。   完成之后，boot loader 开始执行DCSM 和OTP JTAGLOCK流程：DCSM流程：1）读取OTP中的Zx_poinyer；2）解码指针值；3）度去除TI-OTP中的SECDC;4）读取Zx BOOT模式；5）读取ZX DCSM模块   完成之后，boot loader检测FUSEERR寄存器中是否存在错误标志位，并采取错误处理机制   之后初始化RAM和内存端的ECC/PARITY   完成之后cpu1将引导CPU2系统跳出复位操作，之后便不管cpu2的运行状态   之后CPU1系统的boot loader将会根据外部的GPIO 和XRST（一般链接下载器才会有） 来确定程序的启动方式是从flash启动还是ram启动，或者是在XRST为低的情况下，更具PIE向量表（地址为0xd00）的第一个32位的值来确定启动方式（一般是链接了下载器的情况）；   确定完之后，CPU1的boot loader代码段会将各种信息都更新到指定的RAM段中，以便于CPU1的程序去读取这些状态字。   此时按照启动方式开始跳转程序，如果是flash启动则将程序指针跳转到0x80000（flash的其实地址），如果是ram启动则将程序指针跳转到0x00000（ram段的起始地址），同时结束boot loader并进入CPU1的主程序。   如果此时的启动方式是外设启动，那么boot loader则会等待外部程序按照一定的格式将程序加载到ram中，程序代码传输完成之后，跳转到运行指针开始运行程序代码段。   此时cpu1的boot loader 完成使命，已退出，并开始执行CPU1中的用户程序。   此时的CPU2系统知识退出了复位状态，任然在等待启动模式确定，需要cpu1的用户程序来引导cpu2的引导，如果是cpu2也要从flash启动，则通过ipc command即可触发，但是如果cpu2也需要从外设启动，那么需要cpu1的应用首先设置好外设的引脚，之后在触发cpu2开始接受程序。   关于链接下载器的xrst为低是的系统启动过程参考手册 关于外设启动的代码输入格式也可以参考手册   //--------------------------------------------------------------------------------------------   2、实现在线升级的个些方案 ：  次方案是用 ： 升级代码 + 用户应用程序的方式来实现   升级代码的用途是下载到DSP中上电就开始运行的代码段，主要功能是上电之后首先监测是否有升级指令发出，如果有则进入升级流程，如果没有则通过(LB )的跳转指令跳转到指定的程序运行其实处。   假设 ： 将用户应用程序的其实地址定义为0XC0000;当监测到需要升级的指令，则升级代码通过外设将上位机输送过来的代码通过DSP的flash API写入到以0XC0000为起始地址的FLASH sector中，当所有的数据全部书写完成之后，通过跳转指令，将程序指针跳转到0XC0000上，便开始执行用户程序。   数据格式 ： 上位机输送给升级代码的格式就是bin文件当中的内容，dsp将.out文件转化为bin文件，然后dsp接受到这个文件直接写入到flash中就可以，原因是 ：将同一个程序的.out文件下载到dsp中，然后通过uniflsh去查看内部代码段的内容和bin文件的内容是一样的。   至于为什么bin文件和.out文件的格式和datasheet上的数据流内容不一样，我还没找到原因