把一个AURIX工程从一种芯片型号搬到另一种上，并不是只把编译器里那个CPU名字改一下就完事了，因为器件一换，很多底层的东西都会跟着动，比如用来定义寄存器的SFR文件、启动代码、告诉链接器怎么分配内存的LSL脚本、各个寄存器的默认值，还有调试时连到目标板的配置等等。按照TASKING官方给出的说明，即便工程已经建好了，也仍然可以在项目的属性里面去修改处理器型号；如果用的是多核的芯片，那还得重新选一下是让所有核都参与编译，还是只针对某一个特定的核。

　　一、怎样在TASKING环境下切换AURIX工程芯片

　　不同版本的TASKING工具，菜单的位置可能有一点点差别，不过基本的操作思路是一样的。像旧版的VX-toolset，通常是从项目的属性页进去修改；要是换成了SmartCode开发环境，那还可以借由“板级配置”的功能，重新把目标板的配置给导进来。

　　1、先把工程复制一份再动手修改

　　在做任何修改之前，最好在工程视图里面直接复制一份当前的工程，这样手里就多留了一个还能正常编译和调试的干净版本。因为芯片一切换，启动文件、链接脚本这些东西很可能都会跟着变，如果直接就在原来的工程上覆盖着改，万一出现问题，再想退回去找原因就比较费劲了。

　　2、修改处理器的型号

　　如果用的是旧版的VX-toolset，就顺着【Project】→【Properties for】这个路径进去，在项目属性里面找到处理器选择的地方，换成新的AURIX型号。如果是用SmartCode，可以走【File】→【Import】→【TASKING C/C++】→【Board Configuration】这条路，然后选定自己的工程、Debug或者Release配置，再去切换处理器。而且SmartCode官方说明里还提到了一个功能，叫做“更新相关联工程的CPU配置”，专门用来同步那些跟当前工程有关联的项目的处理器设置，避免各工程之间不统一。

　　3、重新把多核的配置确认一下

　　像TC27x、TC37x、TC39x这些包含了多个处理器核心的芯片，切换完型号以后，一定要再去看一眼工程到底是让所有的核心都参与编译，还是只编译某一个核。核心数量的设定、入口函数的安排，还有启动文件的配合，这几样如果没有一起更新好，工程有时候照样能编译通过，但是烧到板子上以后，启动的时候可能就跑不对了，这种情况因为表面上没有编译错误，反而更容易被忽略。

　　二、器件包不匹配的时候哪些地方最容易出问题

　　当工具里装的器件包跟实际用的芯片对不上时，报出来的错误往往会集中在头文件相关的环节和链接那一步，但也可能出现一种情况：程序看上去下载成功了，但外设却一点反应都没有。

　　1、特殊功能寄存器（SFR）文件选错了

　　SFR文件里面保存着芯片各个寄存器的定义，一旦换了芯片，如果工程还是自动把老型号的.sfr文件给包含进来了，那后面编译的时候，就很容易冒出“寄存器不存在”、“重复定义”或者“地址对不上”这一类的报错信息。如果是那种用iLLD驱动库的项目，还得再进到【C/C++Build】→【Settings】→【Tool Settings】→【C/C++Compiler】→【Preprocessing】里面，去看看“自动包含.sfr文件”这个选项到底是开着还是关着，根据当前工程的实际需要来设对。TASKING的官方iLLD说明里也清楚提到过，有些项目是需要把这个自动包含给关掉的，否则构建的时候反而会出错。

　　2、LSL链接脚本没有跟着更新

　　芯片型号变了以后，芯片内部的Flash大小、RAM大小、DSPR、PSPR，还有各个核心专属的那块内存的范围，这些都可能跟老芯片不一样了。如果只是改了处理器名字，而LSL文件还继续用原来那一份，那么链接的时候，就很容易出现段地址冲突、空间装不下，或者是启动代码被放到了一个错误的内存区域里面。好在这类问题只要能通过Board Configuration重新导入一次目标板的配置，它就会帮我们把跟内存相关的设定、链接脚本以及启动代码这几个地方都一起刷新掉。

　　3、启动寄存器跟目标板配置没同步

　　像PLL锁相环的设置、时钟树的配置、启动模式头（Boot Mode Header），还有各种外设的初始化，这些东西都可能跟着具体的芯片型号变化，不同型号之间可能差得很远。拿iLLD的示例来说，它会要求根据真实的目标板环境去调PLL和CCUCON这两个关键寄存器，如果项目需要芯片能脱离调试器自己冷启动，那Boot Mode Header更是得专门配好。在调试的时候，还得再核对一下当前接的到底是哪一块板子、上面具体是哪一种芯片，免得下载器还傻傻地朝着老芯片的那个配置去连，那样连通信都可能建立不起来。

　　三、切换完芯片以后需要检查哪些东西

　　芯片切换的改动都做完以后，不能只看编译有没有通过就算完，最好是按照编译、链接、程序下载，还有外设验证这四个层次，一层一层地往下查，这样才能把潜在的坑提前找出来。

　　1、执行一次完整的清理构建

　　点开【Project】菜单，运行一下【Clean】把以前的旧目标文件全部清掉，然后再进行一次彻底的重新构建。看编译输出的时候，重点留意一下有没有哪里还在引用老芯片的名字，特别是SFR相关的文件、启动文件、LSL文件，还有那些被链接进来的库文件，这几处是最容易带着旧痕迹的地方。

　　2、翻看一下生成的map文件

　　编译完以后，把生成的map文件打开，去检查代码段、数据段、堆栈，还有各个核心自己的内存区域，看它们是不是都落在了新芯片所允许的地址范围里面。只要看到任何地址冲突的提示，最先应该回头去查LSL链接脚本是不是还有哪里不对，而不是一上来就想着去砍代码、压缩空间，因为根源多半还是在内存划分上面。

　　3、到板子上做一组最小化的功能验证

　　先把程序下载进去，看芯片能不能正常启动起来，这算是第一关。然后找一个最简单的串口，再配上一个定时器，外加一个中断，用这三样东西搭一个最小化的测试，看看核心外设能不能动起来。如果程序编译和下载都好好的，但是外部设备却表现异常，那最先怀疑的应该是时钟配置、寄存器定义，还有目标板的设置这几块有没有对好，不要一上来就跑去排查业务代码的逻辑问题。

　　总结

　　关于TASKING下AURIX工程怎么切换芯片，以及器件包不匹配的时候哪些环节最容易冒出错误，处理起来的顺序可以大致这样梳理：先给工程做一个备份，然后再去改处理器型号和多核配置，改完之后紧接着去检查SFR文件、LSL链接脚本、启动代码以及目标板的配置是不是都跟着换过来了；确认这些底层的东西都替换到位以后，再来一次Clean Build，然后打开map文件检查地址分配，最后把程序下到板子上去做一组最小化的启动和外设功能验证。做芯片迁移的时候，把前面这几样配套的东西一起处理掉，比改完CPU那个下拉选项就觉得万事大吉，要稳妥得多。