• 状态
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 319 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

admin
Guru**** 2348430 points
Other Parts Discussed in Thread: TMDSRM48HDK
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/608845/rm48l952-n2het-reading-from-n2het-ram-gives-occasionally-the-real-value-shifted-by-roughly-1

器件型号：RM48L952
主题中讨论的其他器件：TMDSRM48HDK

您好！

我们偶尔会遇到一些问题、现在我们通过使用 CCS IDE 和 RM48开发板(Hercules 安全 MCU 开发套件 RM4 MCU)设法随附项目一起重现这些问题。

我们在现实生活中所要做的事情

HET 运行并计算毫秒时间
2.应用程序每秒读取一次 HET 时间，并将时间经过与等效的 RTI 时间经过进行比较

就像在一个月中发生一次一样、我们收到了一个错误、其中1个故障收到了以下日志：(1000 = RTI_DIFF、2842175 = n2het_diff、d：='DIFF'、t；=允许的容差、 f：=顺序故障、T1：= RTI 'new'-prev'、T2：= N2HET 'new'-'prev'

Drif_ERR：Elaps：1000 vs 2842175、d：2841175、t：3、f：1

时间：T1：2843242-2842242、T2：5682352-2840177

Drif_ERR：Elaps：1000 vs 4292127120、d：4292126120、t：3、f：2

时间：T1：2844242-2843242、T2：2842176-5682352

从 N2HET 接收到5682352的时间就可以看出、这是错误的、因为之前的时间是2840177、而下一个时间是2842176 (1999年介于两者之间)、因此应该已经从 N2HET 接收到2841177或2841176。 由于之前和之前一样收到过完全的考考考考考、因此第二次的课程比较失败(第二次"新"时间正确)。

我们在实际应用中将 EXT_CLK 作为 RTI clk-source、并且我们还通过 DCC 监视 OSCIN&EXT_CLK 是否有效、DCC 满足所有条件。 我们还需要监控时间戳、因为时钟源不会生成有助于"生成"时间戳的时间戳、因此基于此监控、我们发现基于 n2het 的时间戳存在实际问题。


现在、随附的简化项目会发生完全相同的行为、它基本上可以像我们的实际应用中那样执行某些操作、但"快得多"、只需运行它、您就会看到"u32ReadSuccess"与"u32Fails "匹配。 我们已经使用2个不同的 RM48开发板和2台不同的计算机对其进行了测试、这两台计算机位于不同的 IT 组织和不同的地理位置。 请注意、添加了重新读取以说明第一次访问可能失败(预期结果大约为~2倍)和第二次访问提供预期时间的问题。

重现步骤：
1.使用附加的项目并将其下载到 RM48板
2.将 CPU 设置为"run"、等待5秒、然后停止
3.检查'u32ReadSuccess'和'u32Fails '变量

您还可以在 u32ReReadSuccess++行中设置断点、并看到"u32Time"大约是"u32Read "时间的2倍。

注1：您可以将 dma.c 中的代码剪切并粘贴到 sys_main.c 和行为更改
注2：如果注释掉_enable_interrupt_()；则不会检测到故障
注3：如果您修改_enable_interrupt_()函数，以便仅启用 FIQ 或 IRQ (但不启用两者)，则错误仍然存在
Note4：如果您在2个 HET_TimeGet ()函数之间放置__nop()，则错误看起来会消失。

我看到2种可能性

a) N2HET 代码有错误、但我们只是找不到它-仍然无法理解 n2HET 代码中的错误如何会导致 RAM 内容"本身"乘以2、然后恢复...

b)某种程度的 N2HET RAM 访问问题-我从 TRM 中了解到、访问是原子的、并且允许从 CPU 进行访问、并且 ADD 指令是原子的 ("case 110：immediate Data Field[31：0]= IR2")、因此默认情况下、我们正在执行的操作应该是正常的

TRM 20.2.2.1："N2HET 对其自身内部 RAM 的存取优先于来自外部主机(CPU 或 DMA)的存取、"


请指出问题、因为使用该重新读取的实数代码将是"修复症状"而非根本原因、同样基于"去二极管"的实验表明、在进行一些修改后、还会遇到"u32ReadFails (u32ReadFails)"- -另外、我不理解 FIQ&IRQ 使能如何影响这一点、也不理解为什么当您将代码从文件剪切粘贴到另一个文件或添加"nop"... 这是某种管道问题、以便应该给出"MB""DSB"的结构、还是某种问题？

 
这是用于 RM48开发板的项目
e2e.ti.com/.../5444.N2HET_5F00_read_5F00_problem.zip

  • 0
    TI__Guru**** 2348430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Jarkko、

    作为 FYI、我已将您的帖子转发给我们的 NHEE 专家、以便他们设置测试并尝试找出根本原因。 我希望您能在第二天左右听到他们的回复。 如果您没有、请告诉我、我将再次对其执行 ping 操作。
  • 0
    TI__Guru**** 2348430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、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

     

  • 0
    TI__Guru**** 2348430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    无法直接使用.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) 、它看起来会消失...

  • 0
    TI__Guru**** 2348430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好，

    我直接使用了您的输出文件(编译器版本：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 将提高您的代码性能、但不要认为它会解决这个问题。

    请尝试使用新编译器吗？

  • 0
    TI__Guru**** 2348430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    [引用用户="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 时间方法、最初看起来很正常...