最近亚瑟在为Pmod JSTK2IP核心。然而，由于无法预见的困难，他无法让它工作。更糟糕的是，软件认为演示是SPI请求返回的数据在查看参考手册时毫无意义。
他决定自己需要一种能够深入了解demo的方法，并弄清到底发生了什么。幸运的是,数字发现我是来帮他的!
他装上了一个数字发现到一个Pmod TPH energy的JSTK2和Pmod报头之间Zybo．然后，他注意到，在检查Zybo产生的波形时，芯片选择信号(在整个多字节传输过程中应该保持低电平)被驱动程序调高了。这为他指明了正确的方向，但经过临时修复后，他开始出现一系列不同的错误。
这一次，数据仍然是畸形的，但以不同的模式。经过一番复习数据表为PmodJSTK2他再次使用“数字探索”来重新审视这个项目。他注意到SPI的时钟信号到了JSTK2应该小于1兆赫，而他发送的是13兆赫的时钟。
的数字发现这样他就可以轻松地检查信号的定时，脉冲宽度和频率，这反过来又引导他找到了问题所在。修复后的时钟信号问题Vivado和清理的计时芯片选择信号(使用数字发现确认最低持有时间信号被见过),他徘徊在芯片选择确保时候大于25。他发现现在的最佳时间是25.40-完美!
引用Arthur的调试经验:
这是一种需要在SDK中一步一步地调试才能解决的bug，而不能只看来回发送的实际波形。重申第一点，我发现在软件认为没有任何错误，但仍然有非常明显的错误的情况下，数字发现是最有帮助的。
我们喜欢看到数字探索帮助人们实现他们的项目。请在下面的评论中告诉我们您最难忘的或最近的调试经历，以及您是如何解决(或正在解决)这个问题的!如果你想的话了解更多关于数字发现或看到与模拟探索相比，请参阅以上连结及资源中心！
