用DS-5调试复杂问题

分享一个2015我在arm tools研讨会上公开讲的一个主题，如何利用DS-5来帮助大家分析哪些很难处理的软件debug问题。

你是不是也经历过哪些让你束手无策的难题

本人支持过很多客户有关arm CPU和其他IP相关软件问题，深有感触的是，哪些可以频繁可以复现的问题一般都不需要很长时间和精力可以找到问题所在，最难的是哪些不容易复现的，又是随机出现的问题。

比如运行几个小时的Linux突然出现系统挂死，如果开关电压力测试几天突然出现系统不正常。

这些问题足以让人抓狂，让你有力不知道往那里使。

哪些常用的设断点，print的调试手段都没帮助，因为你不知道在设在代码的什么地方。

这个时候你会多么希望有一个好的工具可以帮助你。也许DS-5就是这样的工具。

arm调试构架

早期的时候arm的系统比较简单，调试构架也比较简单，一两条扫描链(JTAG scan chain)就可以搞的。把各种debug的需求，比如设断点，将CPU停下来进入调试模式，并进一步读寄存器，内存值，通过扫描链注入到硬件调试系统。

但是随着arm的系统越来越大，有了多核系统，大小核，各种新的trace(STM, ITM)等在一个系统，原来的一两条扫描链的问题凸显，如果在一个系统里的各种核，trace必须以同样的频率调试，不能有任何一个单元断点，调试速度上不去等等问题。

于是arm引入了新的调试构架，Coresight debug architecture. 这个调试构架的基本原理就是把调试的单元通过调试总线连起来，使各个调试单元独立，因为是总线方式，不会受到不同频率／电源域的相互影响。而且将debug和trace的总线分开（一般debug总线带宽要求低，trace总线带宽要求高）。

DS-5和Coresight

为了使Coresight的debug和trace的功效发挥到最大，你需要一个强的调试器。DS-5集成了这些功能并通过一个直观图形化的界面展现给用户。

实际例子

曾经一个客户被一个Cortex-A57+A53的大小核Linux系统随机挂死问题困扰，他看的这是系统不再活动，没打印，系统没反应。他不知道系统是live lock还是dead lock,更不用说找到root cause.

于是我们帮助他利用DS-5来调试这个问题。

我们试着用DS-5停下系统，看看系统的状态，但是发现DS－5不能使Cortex-A57和Cortex-A53进入到调试状态，在排除其他可能不能使CPU进入到调试状态的状况下，我们怀疑CPU已经由于某种原因硬件挂死了。

那我们需要知道什么原因，甚至是那条指令导致的。

于是我使用了DS－5一个底层调试功能CSAT工具，通过这个工具我能够即使是CPU HW dead lock也可以通过debug 的PC sampling register读到CPU的PC值，通过判断CPU 的PC值是不是在变化，可以看出CPU是不是真的已经HW dead lock. 如果是的话，当时的PC是多少。

这些都是关键信息。