本帖最后由 ndx1986 于 2019-12-8 13:20 编辑
前面两篇帖子分别说了说Ozone的基础功能和Trace功能，链接如下：
基本Ozone的功能也就描述了个差不多了，最后简单叙述个Ozone我觉得相对于Kiel、IAR可能没有的功能（如果也有的话，请留言……）。
工作中有时会碰到一种场景：现场工程师实施、联试的时候发现了问题，但是要么程序不是自己写的，要么有些设计问题可能不太清楚。现在通讯手段会发达些，使用图像、视频会有一个相对直观的印象（远好于之前只能电话的沟通），不过设计到一些细节问题的时候，仅仅使用通讯手段的表达力就会差点事情了。
就我们之前经验，往往是现场工程师不断的电话、截屏、视频回来。如果不是程序问题还好，如果是程序的问题且稍微复杂点，基本就得开发工程师奔赴现场了。
现在如果有了J-Trace配合Ozone，现场工程师可以提供的一手资料就会更详实了。
这就需要用到Ozone的功能-DebugSnapshot（快照功能）：
快照描述
看这个说明的意思，J-Link和J-Trace应该是都可以使用快照的。区别应该就是link和trace的区别了，不过我觉得使用Trace的实际用途会更高大一些。
在程序运行期间，让cpu停在预期的位置（故障点、预期断点等）上。好像不停下来也可以保存快照，不过感觉这样没啥实际意义，因为排查问题应该都有个触发点的位置吧……
随后点击Debug ->Save Snapshots，可以选择自己想保存的相关内容（Memory区、寄存器区） 动图如下：
Save-Snapshot
这个时候，在工程包的文件夹下面会出现一个jsnap的文件，就是当前的记录了
文件位置
这个时候，关闭Ozone，断开J-Trace，再通过Ozone打开这个工程（模拟现场打包将文件发送给其他人一起Debug，其他人只需要具备软件环境就可以了）。注意仅仅快照文件是不够的，需要将工程连带一起打包，否则Ozone也不知道如何来解析。在Debug -> Load Snapshots下就看到我们刚才生成的记录文件。点击ok后，就回到了关闭Ozone前暂停的程序执行界面了。
可以看到，被记录的指令、Timeline跟踪情况、代码覆盖率情况等等都和关闭前（现场）看到的一模一样，这样可以更有效的协同分析了，动图如下：
Load-Snapshot
但需要注意的是，虽然快照保存了最后的执行情况和一段时间的trace记录，但是快照毕竟只是快照，没有办法让我们直接从快照的这个PC的情况下继续向后执行。 （题外话，虽然照相、摄像技术为我们留下了美好的瞬间，但是毕竟是无法回到的过去）
最后一个想说就是Ozone的定位和特点了： 不知道Segger对Ozone的定位是什么。他没有像Keil、IAR（就用过这两个IDE工具……）将Trace也集成进自家Embedded Studio中。 缺点当然很明显，还得分开操作，使用Ozone调试完修正错误了，还得再到IDE工具去编译。 但是优点确实也是明显的，不论Ozone还是ES都是全平台，启动速度非常快，软件本体很小。 Segger我个人觉得相对也是开放的。硬件出身，所以对脚本语言什么的不太懂，但是看到Segger手册里面对Ozone的描述，感觉还是开放了很多接口来提供二次开发的。
Script1
Script2
总结： 花了一周时间，基本对Ozone的使用摸了个底朝天。从最早开始学习嵌入式（大学51试验箱），只会简单的根据写出的程序进行思维逻辑上的判定，到学会使用断点，查看寄存器……
一步步走过去，个人认为多了解一些测试、调试技术手段是非常有必要的。曾经学习、工作中碰到很多情况已经觉得死路一条、无从下手了，但后来对调试手段掌握的多了，回顾之前的很多问题，还都可以发现端倪的。
调试技术手段不单指Ozone、或者J-Trace这样的软硬件工具，更是指发现问题（调试）的想法和思路。
| 
发表于 2019-12-8 13:13:23
发表于 2019-12-9 14:19:31
