转自: http://www.armbbs.cn/forum.php?mod=viewthread&tid=95880&highlight=Ozone

前面两篇帖子分别说了说Ozone的基础功能和Trace功能,链接如下:
Ozone使用介绍-基础功能
http://armbbs.cn/forum.php?mod=viewthread&tid=95855&fromuid=8242
(出处: 硬汉嵌入式论坛)
Ozone使用介绍-Trace功能
http://armbbs.cn/forum.php?mod=viewthread&tid=95867&fromuid=8242
(出处: 硬汉嵌入式论坛)

基本Ozone的功能也就描述了个差不多了,最后简单叙述个Ozone我觉得相对于Kiel、IAR可能没有的功能(如果也有的话,请留言……)。

工作中有时会碰到一种场景:现场工程师实施、联试的时候发现了问题,但是要么程序不是自己写的,要么有些设计问题可能不太清楚。现在通讯手段会发达些,使用图像、视频会有一个相对直观的印象(远好于之前只能电话的沟通),不过设计到一些细节问题的时候,仅仅使用通讯手段的表达力就会差点事情了。

就我们之前经验,往往是现场工程师不断的电话、截屏、视频回来。如果不是程序问题还好,如果是程序的问题且稍微复杂点,基本就得开发工程师奔赴现场了。

现在如果有了J-Trace配合Ozone,现场工程师可以提供的一手资料就会更详实了。

这就需要用到Ozone的功能-DebugSnapshot(快照功能):

看这个说明的意思,J-Link和J-Trace应该是都可以使用快照的。区别应该就是link和trace的区别了,不过我觉得使用Trace的实际用途会更高大一些。

在程序运行期间,让cpu停在预期的位置(故障点、预期断点等)上。好像不停下来也可以保存快照,不过感觉这样没啥实际意义,因为排查问题应该都有个触发点的位置吧……

随后点击Debug ->Save Snapshots,可以选择自己想保存的相关内容(Memory区、寄存器区)
动图如下:

这个时候,在工程包的文件夹下面会出现一个jsnap的文件,就是当前的记录了

这个时候,关闭Ozone,断开J-Trace,再通过Ozone打开这个工程(模拟现场打包将文件发送给其他人一起Debug,其他人只需要具备软件环境就可以了)。注意仅仅快照文件是不够的,需要将工程连带一起打包,否则Ozone也不知道如何来解析。在Debug -> Load Snapshots下就看到我们刚才生成的记录文件。点击ok后,就回到了关闭Ozone前暂停的程序执行界面了。

可以看到,被记录的指令、Timeline跟踪情况、代码覆盖率情况等等都和关闭前(现场)看到的一模一样,这样可以更有效的协同分析了,动图如下:

但需要注意的是,虽然快照保存了最后的执行情况和一段时间的trace记录,但是快照毕竟只是快照,没有办法让我们直接从快照的这个PC的情况下继续向后执行。
(题外话,虽然照相、摄像技术为我们留下了美好的瞬间,但是毕竟是无法回到的过去)

最后一个想说就是Ozone的定位和特点了:
不知道Segger对Ozone的定位是什么。他没有像Keil、IAR(就用过这两个IDE工具……)将Trace也集成进自家Embedded Studio中。
缺点当然很明显,还得分开操作,使用Ozone调试完修正错误了,还得再到IDE工具去编译。
但是优点确实也是明显的,不论Ozone还是ES都是全平台,启动速度非常快,软件本体很小。
Segger我个人觉得相对也是开放的。硬件出身,所以对脚本语言什么的不太懂,但是看到Segger手册里面对Ozone的描述,感觉还是开放了很多接口来提供二次开发的。

总结:
花了一周时间,基本对Ozone的使用摸了个底朝天。从最早开始学习嵌入式(大学51试验箱),只会简单的根据写出的程序进行思维逻辑上的判定,到学会使用断点,查看寄存器……

一步步走过去,个人认为多了解一些测试、调试技术手段是非常有必要的。曾经学习、工作中碰到很多情况已经觉得死路一条、无从下手了,但后来对调试手段掌握的多了,回顾之前的很多问题,还都可以发现端倪的。

调试技术手段不单指Ozone、或者J-Trace这样的软硬件工具,更是指发现问题(调试)的想法和思路。

本主题由 eric2013 于 2019-12-9 14:19 添加图章 版主推荐

版权声明:本文为ramlife原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/ramlife/articles/12222533.html