问题描述：
使用keil μvision5，编译器compiler 6.13编译生产调试程序代码asf，加载到μC/Probe中调试时，碰到无法使用oscilloscope等问题；加载示波器时显示：The oscilloscope control requires some special code running on the embedded target.
出现问题时做如下尝试：利用英飞凌DAVE生成调试文件ELF，然后重新加载到μC/Probe中调试，可以顺利加载oscilloscope功能；考虑两个编译器之间的区别，以及查阅资料。怀疑是否是两个编译器生成的调试文件：asf和ELF之间内容的差别；考虑到这点，将keil μvision5编译器的优化级别从-Oz image size调节到-Oz：
?
然后编译加载到 μC/Probe中，可以顺利仿真。
补充知识
bin、hex、axf和elf文件格式的介绍：
bin 和 hex 大家都不陌生，就是我们下载到芯片的程序文件。
bin文件只是单纯的程序数据，hex除程序数据之外还有一定格式数据。
而 axf 和 bin、 hex 同样也属于程序文件，差别在于 axf 具有更多的调试信息。
用一个表格来区分bin、hex和axf三者的关系：
?你会发现，同样一段代码，编译生成的bin文件最小，axf最大。
在嵌入式Linux中还有一种文件 ELF（Executable and Linkable Format，可执行与可链接格式，由GCC编译生成）也算是一种程序文件，这种文件包含信息更多、更复杂。
下面分别来描述bin、hex、axf和elf这四种格式文件。
?bin文件
????????bin 是 binary 的缩写，直白的翻译即为二进制文件，在这里理解为可执行的机器代码（程序）文件，因为计算机存储只有 0 和 1。
bin 相对于hex、axf是一种最简单的程序文件，只有程序数据，程序文件有多大，程序也就多大。
因此，你下载 bin 程序文件的时候，必须要设置起始地址，比如：通过STM32 ST-LINK Utility工具下载bin文件：
?而hex则不可修改（文件中包含地址信息）：
?hex文件
hex 格式文件由 Intel 制定的一种十六进制标准文件格式，是由编译器转换而成的一种用于下载到处理器里面的ASCII文本文件。
hex行格式：
:BBAAAATT 【D···D】CC
?其中：
: 代表行开始，固定为冒号:
BB代表Bytes，数据长度
AAAA代表Address，地址
TT代表Type，数据类型（标识）
D···D代表Date，数据
CC代表CheckSum，校验和
说明：
BB数据长度，也就是D···D这个字段的数据长度；
AAAA地址，起始地址、偏移地址，根据数据类型(TT)有关；
TT数据类型（标识）：
00：数据标识
01：文件结束标识
02：扩展段地址
04：线性地址
05：线性开始地址
（地址代表高16位地址，也就是要向左移16bit）
CC校验和计算公式：
CheckSum = 0x100 - (Sum & 0xFF)
一个常见hex文件：
:020000040800F2
:1000000000040020B1010008FD020008BD02000844
:10001000F902000801020008350400080000000091
:1000200000000000000000000000000021030008A4
···省略数行
:100470000000024084040008000000200004000086
:040480004804000824
:040000050800019955
:00000001FF04类型：线性地址行
:020000040800F2
?02：数据长度，这里是（0800）地址的2字节长度；
0000：偏移地址，这里数据其实无效；
04：线性地址数据类型；
0800：线性起始地址，左移16位，即：0x0800 0000；
F2：校验和
F2 = ?0x100 - (0x02 + 0x04 + 0x08);
比如，修改起始地址为0600：
?举例分析:
:020000040000FA
:10000400FF00A0E314209FE5001092E5011092E5A3
:00000001FF ? ? ? ??
第1条记录长度为0x02，LOAD OFFSET为0000，RECTYPE为04，说明该记录为扩展段地址记录。数据为0000，校验和为FA。从这个记录的长度和数据，我们可以计算出基地址为0X0000。后面的数据记录都以此地址为基地址。
第2条记录长度为0x10（16），LOAD OFFSET为0004，RECTYPE为00，说明该记录为数据记录。数据为FF00A0E314209FE5001092E5011092E5，共16个字节，记录的校验和为A3。此时的基地址为0X0000，加上OFFSET，这个记录里的16BYTE的数据的起始地址就是0x0000 + 0x0004 = 0x0004. 其实际的数据只有16个BYTE：FF00A0E314209FE5001092E5011092E5。
第3条记录的长度为00，LOAD OFFSET为0000，TYPE＝ 01，校验和为FF。类型为01，说明这个是一个END OF FILE RECORD，标识文件的结尾。HEX结束符一般以：00000001FF结尾。
axf文件
axf格式文件是针对ARM编译器的一种格式文件，它是由 ARM 编译器产生。
axf文件除了包含程序数据（bin）和地址（hex）等数据之外，还包含调试信息。
axf文件内的调试信息附加在程序文件中，有助于分析和调试。
axf文件的调试信息作用：
可将源代码包括注释夹在反汇编代码中，这样我们可随时切换到源代码中进行调试。
还可以对程序中的函数调用情况进行跟踪(通过Watch & Call Stack Window查看)。
对变量进行跟踪(利用Watch & Call Stack Window)。
当然，axf文件调试信息的包含的内容有限，并非所有源码（及注释）相关信息都会包含在其中，想要有效调试，还是需要结合源代码工程进行调试。
elf文件
ELF：Executable and Linkable Format，可执行与可链接格式。
elf是一种用于二进制文件、可执行文件、目标代码、共享库和核心转储格式文件。是UNIX系统实验室（USL）作为应用程序二进制接口（Application Binary Interface，ABI）而开发和发布的，也是Linux的主要可执行文件格式。
---来源百度百科
ELF（Executableand linking format）文件是x86 Linux系统下的一种常用目标文件(objectfile)格式，有三种主要类型:
(1)适于连接的可重定位文件(relocatablefile)，可与其它目标文件一起创建可执行文件和共享目标文件。
(2)适于执行的可执行文件(executable file)，用于提供程序的进程映像，加载到内存执行。
(3)共享目标文件(shared object file),连接器可将它与其它可重定位文件和共享目标文件连接成其它的目标文件，动态连接器又可将它与可执行文件和其它共享目标文件结合起来创建一个进程映像。
elf格式文件由四部分组成：
-
ELF header：描述整个文件的组织。
-
Program Header Table: 描述文件中的各种segments，用来告诉系统如何创建进程映像的。
-
sections 或者 segments：segments是从运行的角度来描述elf文件，sections是从链接的角度来描述elf文件，也就是说，在链接阶段，我们可以忽略program header table来处理此文件，在运行阶段可以忽略section header table来处理此程序（所以很多加固手段删除了section header table）。从图中我们也可以看出，segments与sections是包含的关系，一个segment包含若干个section。
-
Section Header Table: 包含了文件各个segction的属性信息，我们都将结合例子来解释。
程序头部表（Program Header Table），如果存在的话，告诉系统如何创建进程映像。
节区头部表（Section Header Table）包含了描述文件节区的信息，比如大小、偏移等。
?
?
?
?
