主题中讨论的其他器件：HALCOGEN
您好！
我的 RM44代码在 RM44 CPU 上"完美地"运行(OS、DMA、某些外设)、在某些移植工作后、代码在 RM48上运行、但当代码通过调试器停止时、ESM 组3通道7错误被激活。
症状很奇怪、因为如果您执行步进代码、问题可能不会出现、同样、如果我禁用1个任务(立即挂起)问题不会出现、但如果将同一个任务置于延迟循环(仅操作系统延迟)、问题会再次引起。 每次我设法完成整个基于 SafeTI 的 CPU 初始化并启动操作系统、直到出现此错误。
此外、FUNC_ERR_ADD 寄存器显示的 SW 值始终相同、但如果更改代码 A 位、地址可能会略有更改(几个字节)。 FUNC_ERR_ADD = 0x135a98。 我的代码只有0x20000长、并且"相同的代码"(由于需要一些 HalCoGen 更改而不再相同)与 RM44一起工作我强烈怀疑应用中没有任何错误、而且所有 HalCoGen 文件都被 RM48变体所取代 (这也是更改 CPU singe HalCoGen 的疯狂工作，不提供迁移选项，首先使 HCLK 相同，然后使用.DIL 文件 diff &手动将文件从 mfile 移动到其他文件，希望得到最好的结果：)。
我还使用"无代码执行、无专用边缘访问、无用户访问"启用0x130000至0x1400000之间的 MPU、并且不会触发。 通过将 MPU 设置为0x10000至0x20000的应用程序区域来测试 MPU、并生成预取中止。
在开始想 DMA 是否仍然会变得疯狂并执行一些时髦的操作之后、但知道它运行的是非私有边缘、因此假设 MPU 会捕获它、它是否会实际捕获它？ 为什么 MPU 会发现该错误原因、因为 FUNC_ERR_ADD 清楚地表明问题在 MPU 监控区域...
经过数天的果站和读 e2e、并记住几个月前读过的旧帖子、"推测取回"是否会导致这种行为、因为一旦我完全编程整个 ROM、错误就会消失 (对于 IAR IDE、我使用了"linker->checks"->fill from 0 to 0x2FFFFF"选项、闪存实际上花费了很多时间)？
问题：
-为什么我的 RM44没有受到这种推测取操作的影响(从未对整个闪存进行编程)
-为什么步进代码看起来会产生很大的影响，错误是否出现
-您是否真的需要手动对整个闪存编程一次(一次就足够了？ 在调试时始终刷写它所花费的时间太长)
—为什么 MPU 没有赶上它
-在生产中：您需要提供一个包含整个闪存的二进制文件吗？ (基本上、现场更新可以使用正常的二进制文件来完成(如果编程时间很重要)。。)
最后一个
根据症状，是投机取的根本原因，是否有办法从某处检查，因为我不喜欢那些“可怕的失望”的问题，通常这些问题会迟早回来，除非你真的知道它为什么消失
