[参考译文] DRA829V：用于运行时测量的迹线记录的准确性

您好，Thomas：

请提供以下详细信息：
1)您从PDK运行哪种应用程序？  
2)您是否在其他应用中也获得类似的读数？

此致，
第

1)测试不是通过PDK应用程序执行的，而是通过基于PDK启动代码和驱动程序的自定义应用程序执行的。

2)是的，我在不同的应用程序上见过几次。 一位同事也看到A72上的堆栈访问有类似的行为，但我们没有详细调查。

此致

Thomas

您好，Thomas：

对延迟响应深表歉意。  

您能否分享一些参考代码，我可以使用这些代码来复制我的观察结果？

此外，请检查在这些长时间操作期间是否存在任何缓存未命中。

此致，
第

您好，Parth：

问题在于，该影响随机出现在代码的不同部分。 我无法准确再现延迟发生的时间和地点。

在查看 Lauterbach跟踪图时，如果重复调用的函数的执行时间比同一函数的其他调用要长得多，则可以确定发生这种情况的情况。

下面是一个示例(与上面相同的应用程序，但功能不同)：

在描记图中，该功能的"短"执行部分标记为绿色。 在下一个呼叫中，相同的代码需要更长的时间，标记为红色。 当我在此位置显示迹线列表(由垂直蓝线表示)时，705ns运行时间显然是由指令引起的

STR r0，[R13，#0x0C]  

当我看上一个(绿色)呼叫时，同一个指令只花了20毫秒。

堆栈指针R13指的是TCM，缓存被禁用。 在  执行代码期间，PMU也没有报告任何数据高速缓存丢失。 当我步过函数调用时，我得到的每个调用的指令缓存未命中次数始终完全相同(~20)。 但是，很难判断是否也会发生延迟，因为在这种“停止并继续”调试过程中，跟踪数据变得非常无用。  

那么回到五月初的问题：我对劳特巴赫调试器所显示的内容的解释是否正确？ 延迟是否真的是由TCM中的堆栈访问引起的？

什么可能导致这种较大的运行时抖动？

此致

Thomas

您好，Thomas：

查看404.5681万查看 Lauterbach图表时，如果重复调用的函数的执行时间比其他函数要长，则可以确定发生的情况。

所以这个反复调用的函数，是否每次都从同一个上下文调用？ 我想知道这些重复呼叫是如何发出的？

此致，
第

是的，它来自相同的上下文。 这只是一个简单的测试应用程序，用于测量功能运行时。 该函数每500毫秒从计时器函数上下文中调用几次。

对于计时器，我使用OSAL的TimerP功能。  在500毫秒之间，每隔1毫秒会发生另一个由OSAL处理的计时器中断，并执行其他一些要测试的功能。  

此致

Thomas

您好，Thomas：

能否确认函数执行未中断？ 您可以禁用系统中的所有中断(调用测试函数的一个中断除外)，并查看是否看到相同的行为。

此致，
第

您好，Parth：

如果有中断，我 应该在跟踪图中看到它。 但没有。 这会让我回到原来的问题：迹线数据的准确性如何？

是否 存在未被跟踪硬件注意到的中断？

此致

Thomas

您好Richard：

感谢您的详细回答。 我之前已经查看了一些Lauderbachs PDF，但没有查看此特定问题。 我想再次来看一下它们是很有意义的。

解码发生在片外(TPIU)，而ETM时间代码是 ASYNCTIMESTAMPS。

与您在我的其他主题中提到的Snooper功能( TDA4VM: R5F指令高速缓存未命中由调试器引起-处理器论坛-处理器- TI E2E支持论坛)一起，我想我将获得一个很好的方法来了解处理器并找出发生的事情。

谢谢，致以诚挚的问候

Thomas