TASKING

即使工程编译顺利地通过了，最后生成的那份Map文件，也常常会跟事先规划好的内存布局对不上号，比如，变量不知怎么就跑到了错误的RAM区，某个代码段占用的空间一下子变大了，或者有一段地址明明已经设成了固定值，结果却发生了漂移，这些问题，光靠读源码是根本判断不出来的。TASKING链接器在工作的过程里，会把各种目标文件和库文件组合到一块儿，再按照LSL文件里的规则去给它们安排地址，而Map文件里面记录下来的，才是链接完成后真实的内存分布状况。

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

很多团队做功能安全时，最容易把两件事混在一起。一件是工具本身有没有被第三方按ISO 26262认可，另一件是项目在审计时到底要准备哪些落地证据。放到TASKING这里，这两层其实要分开看。官方当前对Arm工具链的表述已经比较明确，VX-toolset for Arm面向Cortex-M和Cortex-R，定位就是面向安全关键嵌入式开发；官方产品页写明其支持到ASIL D，带有Safety and Security Manual，运行时库和浮点库也有符合ISO 26262的合格版本。

在TASKING Arm工具链里，真正决定代码和数据落到哪里去的，不是工程里那几个勾选框，而是LSL也就是Linker Script Language链接脚本。官方文档写得很清楚，新建工程时可以直接把链接脚本文件一起生成到项目目录里，后面再按项目需要去改linking和locating；而链接器本身也支持用`--lsl-file`指定要使用的LSL文件。也就是说，改TASKING ARM链接脚本，核心就是围绕`.lsl`文件来做，而不是单独改某一个输出选项。

很多项目在用TASKING时，编译阶段是顺的，一到链接就开始报错，表面看像是“空间不够”或“段放不进去”，实际往往是几类问题叠在一起：内存区选错了，LSL里的group约束太死了，ROM copy和RAM运行地址没分清，或者map文件根本没有打开足够的信息，导致问题看不清。TASKING官方文档对这件事的口径很明确，链接结果最终取决于LSL里的`section_layout`、group的定位方式，以及map文件里给出的locate和memory信息。

在AURIX项目的开发过程中，如果碰到浮点运算的结果跟预期对不上，很多时候问题的根源并不在算法代码本身。这是因为TASKING工具链会根据当前选择的芯片型号以及编译时指定的选项，自动去挑选对应的C标准库和浮点运行库，这样一来，硬件浮点单元（FPU）有没有被用上、是否退回到软件浮点、单精度还是双精度处理、有没有开启异常捕获模式，这些因素都会直接影响到最终的计算结果。下面就以TASKING VX-toolset for TriCore这一工具为例来说明，虽然SmartCode和不同版本在界面上可能有些差别，但排查的思路是相通的。

在嵌入式开发里面，有一些变量的存放位置是不能完全交给链接器去自动管理的，比如用来做Bootloader共享的区域、存放标定数据的区域、核间通信用的内存、掉电之后数据还要保留的区域，以及跟外设寄存器映射有关的那些地址段。那么在使用TASKING编译器的时候，怎么把变量放到一个指定的地址上去呢？

Tasking Jenkins集成怎么做，很多团队一开始会把重点放在Jenkins插件上，实际上TASKING官方给出的核心能力并不是一个专门的Jenkins插件，而是命令行可调用的构建链路。官方文档明确写到，TriCore工具链自带【eclipsec】这个Eclipse console utility，可以在不启动IDE的情况下做headless build，也可以在命令行生成makefile；同时工具链里还提供【amk】作为make工具。也就是说，Jenkins集成的本质不是“在Jenkins里找TASKING按钮”，而是让Jenkins去稳定调用TASKING的命令行构建能力。

很多人刚接触TASKING Arm工具链时，最容易把“编译器选择”和“库能不能连上”当成两件互不相关的事。可从TASKING官方文档看，这两件事其实是一条线上的前后环节。前面CPU架构、内核名、指令集和FPU选错了，后面链接器就会带错库，运行时和库再怎么补也容易出问题；反过来，库和运行时没匹配好，前面编译虽然能过，最后也可能在链接阶段或运行阶段暴露问题。

做TASKING工程时，很多人以为“编译完成”就只会产出一个文件，其实不是。按TASKING官方文档的口径，链接器默认会生成一个ELF/DWARF调试文件；如果你在【Linker】里的【Output Format】额外启用输出选项，还可以同时再产出Intel Hex、Motorola S-record，某些工具链和输出方式下还能直接生成BIN或C array。真正需要先想清楚的，不是能不能出hex、bin，而是你这份文件到底是拿来调试、烧录、量产打包，还是给后续工具继续加工。

在处理像Bootloader、应用程序分区以及多核工程这类项目时，经常需要调整中断向量表在内存里的存放位置；很多人会关心TASKING环境下的中断向量表该怎么重定向，以及把向量表地址改了以后为什么中断就进不去了，这里不能只盯着链接脚本里那个地址去改。下面以AURIX TriCore工程作为例子来说明，如果用的是其他架构，比如Arm Cortex-M通常靠VTOR寄存器来设置，同样需要去查对应芯片的向量表控制寄存器。

随着工程规模逐渐扩大，代码、常量、全局变量、栈、堆以及启动区全都拥挤在同一套内存布局里，section的放置只要出现一点混乱，链接阶段就很容易报错。想要弄明白TASKING的section该怎么分配才算合理，以及分配发生重叠后又该怎样处理，关键就在于先把内存的用途清晰地划分开，然后借助LSL文件里的memory定义和section_layout规则来控制它们的位置。根据TASKING官方文档的说明，LSL文件正是用来描述硬件架构、可用的物理内存，以及section的放置方式。

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

很多团队把TASKING接进流水线时，最容易卡住的不是编译器本身，而是没先分清授权、命令行入口和批量构建方式。按TASKING官方资料，SmartCode本身支持不启动Eclipse图形界面而直接做headless build，也提供amk这一条make入口；另外，官方许可条款还明确写到，若要把工具放进Jenkins或其他自动化服务器场景，需要具备Build Server License，而不是把普通人工开发许可直接搬进CI。

Tasking TriCore怎么建工程，真正容易卡住的地方通常不是新建按钮找不到，而是工程类型、处理器型号和启动代码这三步没有一起定好。TASKING官方文档说明，TriCore工程可以直接通过Eclipse系列界面里的新建向导建立，项目创建后再由编译器、链接器和启动代码一起组成可执行工程；而启动代码本身负责在进入main之前初始化寄存器和C变量，还带有默认的trap vector table，所以它不是一个可有可无的附件，而是工程能不能正常起来的关键部分。

一个项目原本只需要几分钟就能完成编译，但是在某次修改之后，编译的速度突然就慢下来了，这种变化不一定是由于代码量增加所导致的。当我们想要弄清楚TASKING编译速度为什么会突然变慢，以及编译缓存明明开了却没有起效时该从哪些方面去排查，就要先把全量重编译、缓存连续未命中、头文件连锁变化以及链接阶段耗时这几种情况区分开来。TASKING的SmartCode编译器本身具备缓存中间结果的功能，当源文件经过预处理之后的内容、相关的编译选项以及编译器的版本都维持不变时，就可以直接把已经生成的结果拿来复用，不必从头再编译一次。

程序能够正常下载到目标板里，可每次运行几秒钟之后调试器就突然不受控制了，或者单步执行刚走到某个位置会话便直接断开，这种麻烦在实际调试中经常能碰到，背后常常是目标板的供电不够稳定、调试接口的参数选得不太合适、复位信号出现了异常，或者是看门狗还在后台跑着。在处理这类问题时，不能一上来就反复去改代码，而是应该先把整个连接链路拆开来一项一项地检查，这样才能更快地找到根子。

嵌入式工程编译通过以后，程序能不能顺利装进芯片里，其实只是第一步。要弄懂TASKING生成的map文件该怎么去阅读，以及map文件里关于RAM的占用情况应该先看哪几项，就不能光看一个总数，还得把每块内存区域里面已经用掉的空间、被预先留出来的部分、还剩多少空余，以及最大的连续空洞，这几个指标放在一起去判断。TASKING在编译完成之后，通常会把map文件放在当前构建配置对应的输出目录里面，比如Debug或者是Release文件夹下。要是手头用的是那种图形化的mapxml文件，直接双击就能把它打开，然后通过目录去切换不同的表格来查看。

很多团队第一次做TASKING多核调试时，问题往往不是工程起不来，而是进了调试后只看到一个核在动，或者单步一走现场就乱了。按TASKING官方资料的口径，多核调试要拆成两层来看：一层是工程和启动配置有没有把需要的核真正拉起来，另一层是winIDEA有没有把这些核纳入同步停跑和观察范围。只要这两层没分开，后面很容易把“核没启动”和“核没同步”混成一类问题。

Tasking许可证到期以后，先不要急着重装工具链，更不能直接把“到期”都按一种情况处理。官方资料已经把许可方式分成了客户端型、服务器型、远程许可证服务器和本地许可证服务器几条线，不同线的续费和更新动作并不一样；另外，winIDEA的授权流程还和其他TASKING产品不同，需要单独按许可邮件或知识库说明来处理。先把产品类型和许可服务方式分清，后面的处理才不会走偏。