在armv6 中 已經出現 分類的雛形,但未正式表明
armv6 還沒推出 coresight 架構
armv6 的 debug架構分爲兩塊
1. Debug 模塊
2. Trace 模塊
Debug 模塊
介紹
與之前的不同
ARMv6之前
debug是一個附件，它通過在大多數實現中提供一個嵌入式宏單元建立了一些事實上的標準。
ARMv6
Debug體系結構的第一個版本，它包含了調試規定。
整體擴展概述
在ARMv6協處理器14中，支持被擴展爲提供以下內容：
•調試識別寄存器（DIDR）
•調試狀態和控制寄存器（DSCR）
•硬件斷點和監視點支持
•DCC。
三種特性的更新
ARMv6之前
EmbeddedICE 和 DCC這些特性都是由實現定義的。
ARMv6
EmbeddedICE功能的完整功能集(軟件接口)
1.傳統上僅在外部調試接口上可用
2.例外情況是調試通信通道（DCC）的基於協處理器14的軟件接口，有時稱爲調試通信通道或通信通道。
DCC(軟件接口)
1.爲調試監視器或應用程序提供專用的帶外信息通道，例如，可以使用該通道來支持半宿主功能。
外部調試接口(硬件接口)
1.支持一組最低要求（調試啓用、請求和確認信號），並可用於管理和控制調試事件。
2.ARM推薦的外部調試接口基於IEEE 1149.1測試訪問端口（TAP）和邊界掃描體系結構標準。
ARM規範是該標準的一個子集，僅用於訪問ARMv6調試資源。
因此，術語debug在ARM接口文檔中使用。
1.因此，例如，使用對調試測試訪問端口（Debug TAP）的引用而不是TAP。
2.僅具有相關支持的指令和掃描鏈的邏輯調試TAP狀態機（調試TAPSM）體系結構被指定爲ARM規範。執行調試TAPSM轉換的精確物理接口和機制沒有被描述或被強制要求。
三種特性的支持:兩種調試模式
爲了支持這三種特性,需要（通過其DSCR）配置核心爲以下兩種調試模式之一：
停止調試模式
這允許系統在發生調試事件時進入調試狀態。
當系統處於調試狀態時，處理器核心停止，允許外部調試接口詢問處理器上下文，並控制所有未來的指令執行。
當處理器停止時，它會忽略外部系統，並且無法服務中斷。
監視調試模式 (通過在軟件中設計 預取和數據中止 異常處理函數)
這會導致調試事件導致調試異常。
調試異常通過與預取和數據中止相同的異常向量(DebugMon_Handler)提供服務，這取決於它們是否與指令執行或數據訪問相關。
兩種調試模式對應的調試解決方案
調試解決方案可以同時使用這兩種方法。架構完全支持在這兩種模式之間切換的能力。
最值得注意的例子是支持一個操作系統（或RTOS）
它使用Monitor調試模式運行系統調試（RSD）
使用停止調試模式支持作爲系統故障和啓動時調試的後備。
兩種調試模式都被禁用時
調試僅限於簡單的（通常是基於ROM或Flash的）監視器解決方案。
這種監視器可以使用標準系統特性,從而最大限度地減少對系統資源的需求。
1.使用UART或以太網連接與調試主機通信。
2.它可以使用DCC作爲到主機的帶外通信信道.
在協處理器14中編程向量捕獲寄存器（VCR）
編程, 調試事件發生時,可以捕獲許多異常
不編程，執行流中將發生正常異常。
調試基礎及發展
這構成了ARM®的調試程序員模型（DPM）的基礎。
隨着系統變得越來越複雜，集成度越來越高，調試的重要性也越來越大。
調試從監視核心擴展到監視和分析多個核心以及其他系統資源。預計調試架構將隨着ARM架構的未來版本而發展和增長。
參考網頁
https://max.book118.com/html/2019/0810/8105064107002041.shtm
https://zhidao.baidu.com/question/2117809839472734387.html
https://blog.csdn.net/andy205214/article/details/5408891
- Debug Events and Exceptions
調試事件
調試事件分類簡述：
•軟件調試事件。參見第D2-3頁的軟件調試事件。
•外部調試接口生成的事件，導致處理器進入調試狀態。
這可能是由以下原因造成的：
-激活外部調試請求信號。見第D2-13頁的外部調試請求信號。
-調試狀態輸入請求命令。請參閱第D2-13頁的調試狀態輸入請求命令。
軟件調試事件
軟件調試事件可以是以下任一項：
•監視點調試事件。在以下情況下發生：
-DVA與監視點值匹配。用於比較的地址是虛擬地址還是修改後的虛擬地址是實現定義的。
-WCR的所有條件都匹配。
-監視點已啓用。-持有BRP（如果有的話）的鏈接上下文ID被啓用，其值與CP15寄存器13中的上下文ID相匹配。
-啓動內存訪問的指令被提交執行。只有當指令傳遞其條件代碼時，纔會生成觀察點調試事件。
•斷點調試事件。在以下情況下發生：
-指令是預取的，IVA與斷點值匹配。用於比較的地址是虛擬地址還是修改後的虛擬地址是實現定義的。
-在預取指令的同時，BCR的所有條件都匹配。
-斷點已啓用。-在預取指令的同時，啓用持有BRP（如果有的話）的鏈接Context ID，其值與CP15寄存器13中的上下文ID相匹配。
-指令已提交執行。
-無論指令是否通過其條件代碼，都會生成這些調試事件。•在以下情況下也會發生斷點調試事件：
-指令是預取的，CP15上下文ID（寄存器13）與斷點值匹配。-在預取指令的同時，BCR的所有條件都匹配。
-斷點已啓用。-指令已提交執行。
-無論指令是否通過其條件代碼，都會生成這些調試事件。•軟件斷點調試事件。當BKPT指令被提交執行時會發生這種情況。BKPT是無條件指令。
•矢量捕獲調試事件。在以下情況下發生：
-指令是預取的，IVA與向量位置地址匹配。這包括任何類型的預取，而不僅僅是那些由於異常項引起的預取。用於比較的地址始終是虛擬地址，而不是修改後的虛擬地址。
-在預取指令的同時，設置VCR的相應位（啓用矢量捕獲）。
-指令已提交執行。
-無論指令是否通過其條件代碼，都會生成這些調試事件。
外部調試接口生成的事件
調試狀態輸入請求命令
必須在外部調試接口上有一種機制，可強制處理器進入調試狀態。
發生這種情況時，DSCR[5:2]將被設置爲0b0000。
如果外部調試接口遵循ARM調試接口，則此機制是IR指令
外部調試請求信號
兼容ARMv6的處理器必須具有外部調試請求輸入信號。
這種類型的請求會導致處理器進入調試狀態。
如果發生這種情況，DSCR[5:2]將被設置爲0b0100。
該信號可由ETM驅動，向處理器發送觸發器信號。
例如，如果處理器處於停止調試模式，並且發生內存權限錯誤，則外部跟蹤分析器可以在處理器停止的同時收集有關此觸發器事件的跟蹤信息。
調試事件的響應
處理器以下列方式之一響應調試事件：
•忽略調試事件
•進入調試狀態
•進入調試異常。
響應取決於表D2-1所示的配置。
a.禁用調試時，BKPT指令生成預取中止異常，而不是被忽略。
b.在這些情況下，處理器將忽略調試事件或進入調試狀態，並且在所有情況下都具有相同的行爲。當使用DBGEN通過外部調試接口禁用調試（請參閱第D2-13頁的外部調試接口）時，將忽略這些調試事件。
c.預取中止和數據中止矢量捕獲調試事件在監視調試模式下被忽略。如果處理器在特權模式下運行，並且選擇並啓用了監視調試模式，則也會忽略未鏈接的上下文ID斷點調試事件。如果將BVR設置爲IVA與BCR[22]==0b1進行比較，並且處理器正在特權模式下運行，並且選擇並啓用了監視調試模式，則忽略來自該資源的斷點調試事件。
ARM處理器的傳統外部調試接口基於IEEE1149.1標準。
滿足一些要求,ARMv6實現也可以使用任何其他接口.
Trace 模塊
跟蹤
1.跟蹤支持是一種架構擴展，通常使用嵌入式跟蹤宏單元（ETM）實現。
2.ETM 構造 與處理器操作相對應的 實時跟蹤流。
3.使用ETM是非侵入性的。
4.開發工具可以連接到ETM，對其進行配置，捕獲跟蹤並下載跟蹤，而不會以任何方式影響處理器的操作。
5.跟蹤體系結構擴展提供了運行時系統觀察和調試粒度的增強級別。
跟蹤的使用情況：
•停止核心影響系統的行爲。
•當檢測到問題時，系統中的狀態不足以確定其原因。
Trace提供了一種系統日誌記錄和故障回溯機制。
跟蹤還可用於對處理器上運行的代碼執行分析，例如性能分析或代碼覆蓋率。
ETM體系結構指定了以下內容：
•ETM程序員模型
•允許的跟蹤協議格式
•物理跟蹤端口連接器。
ETM實現定義了
1.跟蹤流
是本地存儲在嵌入式跟蹤緩衝區（ETB）中供獨立下載和分析
還是通過跟蹤端口直接導出到跟蹤端口分析器（TPA）
2.其相關的基於主機的跟蹤調試工具。
ETM相關文檔
ETM體系結構被放到了單獨的文檔。
ETM版本
當前的主要版本（與ARMv6保持一致）是ETMv3。
之後每一種微架構都對應 一種 ETM實現
cortex-M4 的 ETM DDI0440C_etm_m4_r0p1_trm.pdf
cortex-M23 的 ETM coresight_etm_m23_r0p1_technical_reference_manual_DDI0563C_en.pdf
ETM架構版本定義爲一個主要部分和一個次要部分，格式爲ETMvXY，其中X是主要版本號，Y是次要版本號。
ETMv3更新了什麼
•提供更高壓縮級別的跟蹤協議格式
•當FIFO接近滿時自動抑制數據跟蹤，在允許指令跟蹤繼續時防止溢出
•在允許數據跟蹤繼續時禁用指令跟蹤的能力
•從正在跟蹤的處理器控制ETM
•對進程敏感的篩選和觸發
•跟蹤端口與核心時鐘頻率分離。
