轉自: 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 添加圖章 版主推薦