主题中讨论的其他器件： C2000WARE
参考此论坛帖子：
虽然我能够发现 我获得的 ITRAP 是因为函数指针被覆盖、因此发生了无效的函数调用、但我无法弄清为什么函数指针在内存中被覆盖。 实际上、我不相信代码中的任何内容会覆盖此函数指针。 我发现的问题是、假设我为函数指针分配一个空指针、这样它就像 funcPointer =(void*) 0一样。 理想情况下、在编译时间之后、函数指针应该读取0x00000000：
但是，当我第一次按下调试按钮并将代码刷写到 CPU1和 CPU2上时，函数指针值会在我到达 main()之前发生变化。 请注意、我有一个调试配置、该配置设置为一个接一个地对两个内核进行编程。 它将为每个内核构建代码、然后擦除闪存并将代码加载到每个内核上：
0x0608015A 不是有效的空函数指针、因此触发了一个 ITRAP (非法指令 ISR)。 在启动期间、什么会导致这个函数指针在 main.c 之前被覆盖？ 引导 ROM 中的某个内容是否会变为非法并覆盖其他存储器区域？
为了进一步调试、我尝试禁用程序加载/重新启动时的自动运行以单步执行引导 ROM、并查看是否有任何更改函数指针值的操作：
但是、函数指针在整个引导 ROM 中仍然是一个空指针、并且永远不会被覆盖(即、如果程序加载或重新启动时自动运行被禁用、我无法复制被覆盖的函数指针)。 一旦我 在 程序加载或重新启动时启用自动运行至 main 并尝试再次闪烁、问题就会重新出现...这让我感到很不快。
这是另一个褶皱。 如果我已经处于活动的调试会话中、那么在我第一次将代码加载到闪存中的两个内核后、我无法复制此问题。 如果我尝试 CPU 复位/重新启动、函数指针返回到正常值0x00000000。 这个问题似乎只在我第一次启动一个新的调试会话和闪存代码到两个内核上时发生。 我必须停止当前调试会话并重新启动调试会话、并将代码刷写到两个内核上、以便再次查看问题。
仿真器调试器模式、引导 ROM 或链接器 CMD 文件设置不正确、这是否是一个奇怪的问题？ 这里有一个针对"Memory：Prepetching Beyond Valid Memory"的勘误表、因此我必须研究我们是否使用勘误表 SPRZ413L 中指定的 M1 GS11或 GS15。 仔细检查了链接器文件、它们 特别不允许按照勘误表使用无效存储器区域的结束、因此似乎不会出现链接器文件的问题。 尽管 我确实合并了 RAMLS0和 RAMLS1、以便在 CPU1上为 TI ramfuncs 生成 RAMLS0_1 (CPU2仅需要 RAMLS0)、但不确定这是否会影响任何内容。
编辑2021年5月12日： 清理并简化了问题
