Jlink 想必大家都用过，相信登录过 segger 官方网站，下载最新的 jlink 驱动程序的时候，都会看到这样的图片：
在兴叹它那离谱的价格的同时，也会好奇这个东西比手里的x版货都有哪些优势和提升。
以上图片是 segger 官方对 J-Trace 的定位：
使用基于 segger 领先的 trace 方案 J-Trace PRO 实现对代码的收集、验证、分析功能。利用 Arm Cortex 内核的 trace 功能，在无限时长内，实现对所有指令的跟踪，实现对偶然出现的、难以被复现的 bug 追踪记录。
在完整的 System Clock 内实时流式传输 trace。
使用在线代码分析功能来精细优化代码。
指令级别的代码覆盖率检测，为满足安全性规约约束的需求。
无限制的 trace 追踪，实现隔离和识别潜在的代码缺陷。
完整的 J-Link 调试功能
可以看出它最大的卖点就在 arm trace 的信号流捕捉和分析，实现代码的精确流程跟踪，有了精确的代码跟踪，就可以借助 Ozone 工具提供实时分析代码覆盖率、指令回溯、CPU 资源监控等功能。
这么多优点，配合强大的 Ozone 调试平台，code coverage 实时统计，一键生成报表，boom。仿佛那最后的 bug 就可以用它来反复蹂躏、踩在脚底...感动人心！直到看到售价：
Price: €1,980 EUR
这个价格可以买一台高配的 MacBook 了，但对比其他支持trace接口的调试器来说，性价比出众，例如 trace32。
如图所示 segger 的 19 pin trace 接口（1.27mm 牛角），在 JTAG 基础上增加了 5 条 trace 线（4 条数据线 + 1 条时钟线，双边沿模式(DDR))。
有一点要注意一下，不要把两个接口都接到板子上：
Note: Never connect trace cable and JTAG cable at the same time because this may lead tounstable debug and trace connections.注意：不要同时使用 trace 连接线和 JTAG 连接线，这将导致 debug 和 trace 的不稳定现象。
参考：《UM08001: J-Link / J-Trace User Guide》
既然本篇目主要介绍 J-Trace 的入门教程，自然就需要有这么一台设备支持一下了。
三句话，让老板为我花了1W8，终于拿到它：
你要问盒子里有没有跳线帽，这个真没有：
可以看见这个板子使用了 ARM cortex A9 + FPGA 的 Zynq-7010 作为主控，通过 Zynq 专有总线与赛普拉斯 CYUSB3011 USB3.1 控制器连接，CYUSB3011 内部也具备一颗 ARM926 200MHz 的控制核心，用于协调 USB3.1 高速传输协议。
周边还有美满的千兆 phy 收发器，芯成的LPDDR2 128MBytes 533Mhz，用于高速收发和缓冲 trace packet，对于电脑主机来说尽量配备大内存和独立的 USB3.0 接口。
外围就是一些电平转换电路和电源了，都是 TI 的一些常见型号，总的来看 JTAG 和 trace port 的逻辑由 FPGA 硬件逻辑实现，当作 J-Link 可以用 zui 高速调试，下载效果要好很多。
在上一节我们简单介绍了 J-Trace ，至于为什么三句话说服了老板，我们还是要以专业视角看 trace 的引入能够解决哪些实际的问题。
J-Trace 的标准包装很“贴心”地赠送了一张 STM32F407 核心板，它用的不是标准 Jtag 接口，而是支持 Trace 的接口，我们可以像官网那样去连接和测试 Trace 功能：
翻看 STM32F407 的 RM（RM0090.pdf） 手册，找到 Debug support 章节，可以看见 芯片内部负责 Debug 的系统框图：
可以看见我们主要关注且日常见到的一些片上调试模块：
SWJ-DP: Serial wire / JTAG debug port
AHP-AP: AHB access port
ITM: Instrumentation trace macrocell
FPB: Flash patch breakpoint
DWT: Data watchpoint trigger
TPUI: Trace port unit interface
ETM: Embedded Trace Macrocell
以及文中提及到，STM32F4xx 系列支持的扩展功能：
Flexible debug pinout assignment
MCU debug box (support for low-power modes, control over peripheral clocks, etc.)
归纳一下就是：
SWJ-DP 这个大家都熟悉，不必介绍，其他的也许使用过，但多数情况下我们不会在意它们的存在。
ITM 可以支持 SWO 输出调试，挖个坑下回填。
很多定位中低端的MCU就直接丢弃掉 Trace Port 相关电路单元了，加上对外接调试设备的高要求（贵）以至于很多工程师并不知道 ARM Cortex 上其实还有 JTAG/SWD 之外的调试端口。
本文重心围绕指令追踪，我们重点来看 ETM：
对于ETM，需要了解：
ETM 的主要任务是帮助开发者重建程序执行序列，CPU 上所有指令的执行都可以被 ETM 追踪到。
数据可由 DWT 或者 ITM 单元追踪到。
Embedded Trace Macrocell (ETM) 提供结合了 ARM 的调试和追踪机制，它可以做到在不干扰 CPU 的情况下获取 CPU 的运行状态，一旦捕捉到，便实时通过特定的 Trace 端口向外输出。
具备 ETM 模块的 MCU 可以实现详尽的指令执行历史记录，这些记录可以作为重现代码流程和执行时间的依据，使用分析软件实现代码分析，借此找到难以复现的bug。最难能可贵的是，它可以帮助我们找到失控的代码的根源所在。
此外，ETM还有更多特性有待进一步了解，比如常见的 ETB、Filter & Package Formatter 等细节属性，有待进一步啃手册了。
更多有关 ETM 资料，请翻阅《Embedded Trace Macrocell Architecture Specification》 、《ARM CoreSight Architecture Specification》 、《ARMv7-M Architecture Reference Manual》
综上，ETM 并不是对外输出的最终形式，在 STM32F4xx RM0090.pdf 中有如下结构：
可见 ETM 和 ITM 生成 CPU 运行的追踪信息后，由 TPIU 模块执行封包，并使用对外已经连接的序列器输出，由这张图片可以得出以下结论：
终于涉及到物理层连接了，自然就会引出物理连接概念：Trace signal timing （追踪信号时序）
上一章节我们知道 ETM 信息是可以和 CPU 同频的，以达到最佳的指令追踪覆盖效果，对于 Cortex-M 架构，ARM 有如下定义：
trace 时钟往往是 1/2 的 CPU 时钟，但是 trace data 线路可以是 DDR （双倍速率-亦称上升下降沿）方式通信，通常 data 线有4条，意味着一个 trace 时钟周期可以输出1个字节的 trace 数据。
trace 硬件接入，笔者经验总结：
如今 MCU 主频也在不断递进，为了保持高速的 trace 也必然对线路阻抗与信号输出能力提出了更苛刻的要求。由于是 DDR 方式地获取追踪数据，所以在 Layout 上就需要做好等长，为了保证良好的 trace 稳定性，也应当从 MCU IO 翻转输出能力和CPU主频两个角度的上限妥协一个较为稳定的时钟速率。
由于是高速 DDR 信号，时序上要尽量满足以下要求：
Trace CLK 作为时钟基准，如上图所示 Trace Data 被时钟上升或下降沿一分为二（50%占空比）是最佳的信号效果，如果 Trace Data 出现了较多的超前或者滞后，也可以在 Ozone 中设置延迟补偿，这里不过多介绍了。
Trace 能够帮助解决面向过程测试中，以不干扰CPU正常运行为前提，揭示程序运行踪迹，解决最麻烦的bug。
Trace 辅助工具可以实现代码分析与实时覆盖率统计，帮助我们以直观运行视角，揭示代码优化方向。
这套工具除了贵没别的不好，Ozone 调试功能强大且好用，它是免费的，只需要有 J-Link 就行。
下一篇我会介绍 J-Trace 的具体使用过程，展示 RT-Thread 在 trace 上的效果，敬请期待。
你可以添加微信17775982065为好友，注明：公司+姓名，拉进RT-Thread官方微信交流群！
👇 点击阅读原文进入官网
