[参考译文] RM48L952：N2HET：从 N2HET RAM 读取偶尔会得到由大约&lt 位移的实际值；&lt 位移；1.

您好、Jarkko、

我在 我的机器和 RM48Lx HDK 上运行测试用例(已连接)、但无法重现问题。

附件是您 发布的项目、但我做 了几个小的修改以消除编译错误：

导入到 CCS7.1中时、编译器版本为16.9

2.添加了" uint32 u32HetClkDiv；"

3将"lkDiv = u32HetClkDivider()；"更改为"u32HetClkDiv = u32HetClkDiver()；"

e2e.ti.com/.../5850.N2HET_5F00_RAN_5F00_READ_5F00_TEST.7z

无法直接使用.zip 中的.out 文件、也无法使用我们正在使用的相同 CCS IDE 版本、因为我们不必与其他计算机进行任何操作即可将该项目导入其中并运行和检测相同的故障？

请注意、我们最初在使用 IAR 编译器时遇到了这个问题、因此编译器不应影响这个问题、因为我们也在使用 CCS 时得到这个问题。 但是、由于已经注意到这个"演示项目"、即使只是微小的变化也可能改变代码运行方式、这就是为什么设置应该是"完全相同"的原因、我认为这可以通过使用.zip 中的.out 文件和相同的 RM48L952ZWT CPU 来实现...

我们的开发板封装的背面似乎有贴纸、上面有以下数据：TMDSRM48HDK

这就是我们得到的结果(对于2个不同的电路板和计算机、其他计算机刚刚导入项目并按原样使用该项目、还验证了例如、在故障消失后、在导入的项目中删除中断使能功能、如在第一台计算机中)： 代码在停止前已运行~6814ms (只需在系统复位/下载后运行代码-等待一个位-按下"暂停"(alt+F8))、在此期间、我们在"主读取"中遇到253次读取失败、这种失败出现在"次读取"中。

在这里、您可以看到第一次读取的内容、以及首次失败计数时的重新读取时间(前推时间= 25、时间= 50、读取= 26)

根据您的项目、您实际上没有更改任何内容、即使您说要进行更改才能编译代码、只需在为其分配值之前声明变量(未使用 HetC)？ u32HetC 或 lkDiv 来自何处、不应位于我们的.zip 中？

您的：

   uint32 u32hetC；
   uint32 u32hetClkDiv；
   //lkDiv = u32HetClkDiver()；
   u32HetClkDiv = u32HetClkDiver()；

我们的：

uint32 u32HetClkDiv = u32HetClkDiver()；

使用 sys_main.c (在我们的项目中)、故障仍然存在

让我们还阐明以下几点：

a)可以像我们所做的那样从 HET RAM 中读取数据、不需要额外的东西？
b) N2HET 代码中是否有任何问题或者它的使用是否有问题？

c)不应该有理由使用 HTU 来将数据从 N2HET RAM 传输到 CPU RAM (这是一个尝试的计划、如果它有助于提供始终有效的值的话)？

是的、我/我们知道整个线程看起来非常奇怪、但正如您从屏幕截图中看到的、这是一个真正的问题和实际的问题(也涉及 CCS 和开发板)。 我们花了很长时间才找到"症状"的原因是、最初我们没有打印出当前和以前的值的调试打印、我们只打印了扩散、容差和故障计数(第一行)。 最初、我们认为这可能是调试器的某种"干扰"或 32位 n2het 数据中的"环绕问题"、但我们将 n2het 时间初始化为接近环绕点、并注意到它工作正常、因此我们让它一直持续到它再次命中、 然后、我们添加了更多的打印件、上周、我们收到了第一个实际故障、并改进了打印件、并注意到 n2het 读取的值"疯狂"。 然后、我们"加速"了监控(将其从1s 移动到1ms)、并注意到它崩溃的速度很快。 然后我们添加了重读、并注意到它始终正常。 之后、我们决定删除我们的应用(操作系统、中断等)并建立这个基于 CCS 的演示、只是为了注意错误仍然存在、并且有一些细微的变化、这些变化不会影响 RAM 读取(例如启用 IRQ) 、它看起来会消失...

您好，

我直接使用了您的输出文件(编译器版本：arm 16.3.0.STS)、并遇到了以下问题：

2.我在计算机上使用 ARM16.9.1.LTS 编译了该项目、但无法重现问题：

3.我看不到您的 NHET 微代码中有任何问题。 我想使用 MOV32或 MOV64来更新数据字段和控制字段。

4.您用来读取 NHET RAM 的方式是好的。

5. HTU 是 NHET DMA (在 PCU 操作的后接部分与 SRAM 之间传输 NHET 数据)。  使用 HTU 将提高您的代码性能、但不要认为它会解决这个问题。

请尝试使用新编译器吗？

您好！

[引用用户="QJ Wang "]

我直接使用了您的输出文件(编译器版本：arm 16.3.0.STS)、并遇到了以下问题：

[/报价]

很高兴错误被复制了！

[引用用户="QJ Wang "]
3.我看不到您的 NHET 微代码中有任何问题。 我想使用 MOV32或 MOV64来更新数据字段和控制字段。

[/报价]

抱歉、我的英语不好、您是不是说 MOV32操作"次优"、因为它根本不使用？ 否则、我们如何获得 ADD 指令将数据字段增加1 (现在 MOV32的数据字段只是用作值1的占位符、MOV32指令根本不会被执行(请参阅 BR 指令分支)。 您认为这可能对读取问题有任何影响吗？

[引用用户="QJ Wang "]

5. HTU 是 NHET DMA (在 PCU 操作的后接部分与 SRAM 之间传输 NHET 数据)。  使用 HTU 将提高您的代码性能、但不要认为它会解决这个问题。

[/报价]

我尝试 HTU 的动机是圈出 CPU 对 N2HET RAM 的直接访问/读取、因为 HTU 似乎有一些问题、CPU 会从自己的 RAM 中读取相同的值 (DMA 也可用于该传输、但由于 HET 只有1个 DMA 触发器、因此希望将来保存这些触发器-可能仍值得测试)、根据代码/编译器、这些触发器可能存在、也可能不存在。 当然、无法确定问题是否在读取中、它只是基于代码行为而出现的。。。 如果 HTU 方法起作用、那么它将是某个东西的指示(不知道什么而是什么)。。。
[引用用户="QJ Wang "]

请尝试使用新编译器吗？

[/报价]

当然、我可以尝试更新的 CCS (不能尝试更新的 IAR)、但由于 IAR 存在同样的问题(这是我们的主编译器)、我看不到尝试更新的 CCS 版本有什么好处(我相信您的测试中、同一代码不会检测到失败、 由于.out 不同(与项目中的.map-file 不同)、如果您稍微修改代码、仍然可能会出现故障。 即使这样、我们的 CCS 版本也发生了轻微的代码更改(例如向不会遇到故障的代码添加"nop"或注释掉 IRQ/FIQ 使能、但如果您将 dma.c 内容剪切并粘贴到 sys_main.c、则重新读取也会偶尔发现故障。 IAR 测试代码的结果略有相似(因为消除错误看起来要困难得多)、常见的情况是、对代码所做的任何更改都不应影响 n2het RAM 的读取、但仍然会影响 n2het RAM 的读取。


由于您设法重现了此问题、我希望 TI 告诉我们错误的地方以及如何解决、这超出了我/我们的专业知识范围、我认为这是无法通过基本调试器解决的...

尝试"某件事"并不有效、因为这样您很可能无法找到根本原因... 这可能是一种非常简单的方法、例如在读取前添加一些流水线冲洗或其他内容(但根据 TRM、似乎不需要任何特殊的东西、正如您在3中确认的那样。 和4.) 或者、这是勘误表材料、需要执行一些特殊程序才能以永远不会出现问题的方式将其圈起来...

由于安全现场总线需要这段时间(它需要来自不同时钟源的2个时间戳、并且现场总线堆栈计算两个时钟源的时间间隔并需要更长的时间)、因此这个问题在将来会对我们更是阻碍。 由于我们的"监控器"故障很可能在现场总线堆栈内发生(尚未在该器件中运行该现场总线)、因此它会计算疯狂的时间间隔、并且现场总线协议会提高超时和器件跳闸... 对于当前代码、我们需要"健全检查"给定给堆栈的值、如果得到了疯狂值、则重新读取、直到接收到"更好"的值并将其传递给堆栈-这是我们现在不想做的事情、尤其是因为目前我们不了解根本原因...


最初、我们使用 RM44系列器件、之后我们使用了2个 eQEP 模块(第1个外部时钟分频为毫秒基值、其输出被环流至第2个 eQEP 输入、然后直接计算毫秒)来产生第二个毫秒时间、 它运行顺利、但该 RM48系列没有 eQEP、因此我们发明了这种 N2HET 时间方法、最初看起来很正常...