在AURIX多核项目的实际开发中，很多时候工程文件可以顺顺利利地编译通过，但这并不表示每颗核心都已经按照我们设想的那样跑起来了；只要在配置阶段漏掉了核心的启动开关、启动文件，或者链接脚本里某个地方没写对，就很容易碰到Core 0正常进入主程序、而其他几个核心却一直停在复位状态里不动的情况。要想弄明白TASKING环境下的多核工程到底该怎么配置，以及多核启动的顺序出了问题该从哪个方向去查，比较实际的做法是从工程模式、启动配置、分核的入口函数，还有最后的链接结果这四个位置，一步一步地去确认。

　　一、TASKING多核工程怎么配置

　　在刚刚开始搭建一个多核工程的时候，首先要保证处理器型号和核心模式这两样都选对，如果最初是按照单核工程去创建的，到后面再想把它硬改成多核结构，那么启动文件和整个链接布局往往就得重新整理一遍，反而更耽误时间。

　　1、选对芯片的具体型号

　　先通过菜单栏的【File】→【New】→【TASKING TriCore C/C++Project】这条路径来新建工程，填好工程的名称，然后在器件选择界面找到手头那块板子上真正使用的AURIX芯片。这里要留个心，不能用看起来差不多的型号去代替，因为不同系列的芯片在内部的核心数量、存储区域的划分，还有上电启动时的配置上，都可能存在差别，一旦型号选岔了，后面很多设定就都对不上了。

　　2、启用多核模式

　　在工程向导的多核配置页面里，我们要把【All cores】这一项给勾上，要是只选了其中一个核心，那创建出来的工程就会按照单核的方式去搭建，不是我们想要的多核环境。如果项目确实需要Core 0、Core 1和Core 2这多颗核心一起配合工作，那最好从一开始就老老实实用多核工程模板来建立，能省掉很多后面改写配置的麻烦。

　　3、加入启动文件和链接脚本

　　创建工程的时候，向导会询问要不要把启动文件和LSL链接脚本一起带进来，这两个文件对于多核系统来说是缺一不可的，启动文件负责完成堆栈的初始化、数据区的准备，还有引导每个核心启动的那一套流程，而LSL文件则负责给各核心的代码段、私有数据、共享变量以及内存区域安排好对应的地址空间，万一少掉了其中任意一个，工程可能照样编译得过，但运行起来的结果就不完整了。

　　4、把共享数据和核心私有数据分开管理

　　多个核心会一起访问的那些变量，一定要规规矩矩地放进共享数据区里面，而只由某一颗核心单独使用的数据，就放到它自己私有的区域里去，不然等到运行的时候，很容易看到数据更新不同步、某个核心读到的变量值莫名其妙地变掉，或者个别核心怎么也拿不到最新的计算结果这些现象，排查起来很头疼。

　　二、TASKING多核启动顺序该从哪里检查

　　AURIX这颗芯片在上电复位以后，通常是由Core 0先跑起来，再由Core 0去把其他核心一一唤醒，所以，一旦发现有哪颗核心没有在运行，先别急着去翻业务逻辑的代码，而是应该去把整条启动链路从头到尾查一遍，看看是哪个环节卡住了。

　　1、确认核心启动开关是否打开

　　进到工程的启动配置页面里，去翻看一下【Start TC1】和【Start TC2】这一类的选项有没有被启用，虽然多核工程模板会帮我们预置好一部分启动代码，但这并不代表其他核心就一定会被默认设定为自动启动，只要这个开关没有打开，Core 1和Core 2就压根不会进入后续的自举流程。

　　2、检查Core 0的启动代码

　　找到Core 0对应的那个启动文件，仔细核对一下里面给其他核心指定的启动地址、复位入口，还有发出的启动命令是不是都写对了，因为Core 0必须先完成一整套基础硬件的初始化，然后再把其他核心从复位状态里释放出来，如果启动地址不小心填错，那么被释放的核心可能会停在某个奇怪的地方，或者干脆就跑飞到错误的区域里去。

　　3、检查分核入口函数

　　当这些核心进入应用程序以后，一般都会根据当前核心自己的编号，分流进不同的主函数，比如像core0_main、core1_main和core2_main这样，我们可以在这些入口位置分别打上断点，然后实际跑一遍，看看每颗核心是不是真的都走到了属于自己的那个任务函数里面，没有进来就说明前面启动或分流环节还有问题。

　　4、检查同步和等待逻辑

　　在多核启动的过程中，程序里经常会设置一些同步标志位或者屏障，用来等待其他核心完成各自的初始化动作，万一某颗核心由于前面已经出了问题而没去更新那个同步标志，别的核心就可能永远卡在等待的位置，调试的时候就要重点去看同步变量的值、等待的条件是否合理，以及有没有设计超时处理机制。

　　三、TASKING多核工程异常怎么反查

　　碰到多核工程运行异常时，光靠串口打出来的那一丁点儿日志是远远不够的，因为日志没有输出，既可能是核心压根就没启动，也可能是任务没被调度进去，还可能是共享变量的配置本身就有问题，所以我们需要把调试器和map文件这两样工具配合着来用，才能更准地摸到根子上。

　　1、给每个核心的入口打上断点

　　分别在各个核心的初始化入口和任务入口处把断点设好，如果全速跑起来以后只有Core 0能命中，那就要回过头去查启动开关和Core 0释放其他核心的那段流程；要是各个核心的入口断点都能命中，但就是进不去任务函数，那就要把注意力放到调度机制和分支逻辑上面。

　　2、查看map文件

　　编译结束以后，把map文件打开，看一看各个核心的代码段、栈区、共享数据区还有私有数据区，是不是都老老实实地落在了我们规划好的地址范围里面，如果共享变量被错误地分配进了某个核心的私有区，那么程序表面上也许能正常跑起来，但是数据交互这一块就一定会出乱子。

　　3、保留一份最精简的测试工程

　　当正式项目的逻辑变得很复杂的时候，不妨单独留一份只包含了多核启动、少量共享变量和简单循环的测试工程在身边，以后不管是升级TASKING版本、修改LSL脚本，还是更换芯片型号，都可以先用这份最小的工程来验证整套启动链路是不是还通畅，等验证通过了，再把改动合并进正式的工程里去，这样能避开很多混合型的问题。

　　总结

　　概括下来，配置TASKING多核工程的时候，首先要选对AURIX芯片的型号和【All cores】模式，然后加好启动文件和LSL脚本，并且把共享数据和核心私有数据分清楚；到了排查启动顺序这一步，重点要去检查其他核心的启动开关到底打开了没有、Core 0释放其他核心的那一段流程写得对不对、分核的入口有没有被跑到，以及同步等待的逻辑是不是完整；再配合着打在各核心入口的断点和编译出来的map文件，一项一项地确认，通常就能比较快地定位出多核工程到底是卡在了启动的哪一步上。