ARM学习(18) Jink Ozone调试总结

笔者来聊聊Jink Ozone调试

1、Ozone加载选择elf或者bin

Ozone调试的时候可以设置PC的位置，主要有上面两种

1. 从ELF读取PC位置，调试时直接设置PC的初始位置
2. 从向量表中读取pc的初始值，例如cortex-m3/m4 就是bin文件第二个u32值，第一个是sp的值

加载elf/axf

axf其实遵循的就是elf的格式，大概可以理解为改了后缀名而已。

如果加载axf，可以download或者也可以直接attach上去，不reset。

总共有三种模式：

1. download and Rreset Program ：下载代码和 复位程序
2. attach to running program ：链接到正在运行的程序，程序也一直保持运行
3. attach & Halt Program：链接到正在运行程序，但是停止程序
   

笔者这个是直接download程序，可以看到下面Console中的内容

1. Elf.GetBaseAddr()，return 0值
2. read U32 （0x0）return 0x30000，这是sp值，
3. Elf.GetEntryPointPC() return 0x25C,ELF格式中会带有初始程序值（下图2） Entry Point Address：0x25d，所以设置pc 为该值。
4. Startup complete （pc=0x54c），因为程序断点设置在main函数这个符号，看图1右下角，所以pc此时停在该位置，图3 通过符号表也可以看到这个信息
5. 假如将该断点的符号设置为ResetISR，复位中断函数，则会看到断点会停在该函数，如图4，0x25C。

说明：因为CortexM4- 都是thumb2指令，所以地址都是奇地址，看到0x25C和0x25D是一样的

图1

图2

图3

图4

加载bin

如果是下载bin，建议就选择从向量表中读出pc（Read from Base Address Vector Table），地址就填加载地址即可，STM32:0x08000000 LPC则可以填：0x0地址

因为bin文件中没有符号表，所以会提示无法断在main这个符号这里，所以他的断点就停在了开始位置，即从向量表里面read出来的地址，即0x25C位置。其他的显示和axf加载是一样的。
)

STM32 axf Download问题

在这里STM32使用Ozone的时候，碰到一个问题，axf下载程序运行不正常，但是bin下载则正常。
首先分析：查看各自下载的是程序启动情况，图1是bin下载，图2是axf下载。

1. 首先发现SP的值都是设置的正常的，
2. axf设置的PC的是0x08000150，最终pc停在main函数，地址是0x0800C2E8，但是bin设置的PC是0x080001CD，初始PC就不一样，执行效果肯定不同
3. 经过定位，发现axf设置pc的位置在__main，如图3，bin下载设置的pc位置在Reset_handler，如图4，符合预期，则验证了为什么bin下载的是正常的，因为程序执行正常，但是axf下载执行异常，是因为其下载的就异常。
4. 追其根本原因，发现axf文件头的位置就是0x08000151，说明axf编译有问题，导致Ozone按照axf调试则出现问题，如图5
5. 查询ARMCC 编译器手册，发现链接选项 --entry 可以指定程序入口点，如图6，增加之后，编译出程序运行正常，axf显示入口点也是正常，图7图8显示。

图1

图2

图3

图4

图5

图6

图7

图8

2、Ozone远程调试

远程调试的端口是19020，jink与板子的链接方式是USB，Ozone与Jink通过TCP/IP方式进行链接，地址是xxx:19020

3、Ozone断点调试正常，全速运行就异常

遇到正常情况，有几种情况，

3.1 调试运行正常，但是全速无法进中断

情况如1中所介绍的STM32问题情况一样，

1. SystemInit函数中设置中断向量表的偏移， SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; / Vector Table Relocation in Internal FLASH /，图2
2. 由于误操作，VECT_TAB_OFFSET改为其他值，导致全速运行时，无法找到中断向量表，无法跳入到函数入口，一中断就卡主（疑似跑飞）。如图1
3. 调试的时候为什么正常呢，因为跳过了system_init的执行，中断向量表偏移默认值是0，则不偏移，程序正常可以跳入中断执行。
   
   图一
   
   图二

3.2 调试运行正常，但是全速程序卡住在异常函数口出

这个可能每个调试器都会存在这样的情况，调试器会干预CPU的执行，强制程序跳入下一行，

1. 很明显的例子比如 ：乱序执行，接上调试器之后，则按照正常执行，就不会乱序执行了
2. 再说回来，程序卡在异常入口函数出，由于调试器的原因，会因为将数据识别为函数符号，程序继续执行了，但是全速运行，无法识别为函数，则跳入异常，，每次都进去异常，表现为卡在函数口。
   
   图1

图2
正常 Ozone 调试看到的地址，异常情况下，图4函数由于没有声明为function，所以运行时，无法认为是函数（最低位不是0,thumb指令）所以出现异常，使用异常，企图切到arm状态，如图5，而且由于状态错误，反复进入异常，反复进不去，导致异常，现象就是卡在异常入口处。

图3

图4

图5